On Mar 4, 2018, at 3:54 AM, Dimitris Vyzovitis vyzo@hackzen.org wrote:
The first problem is truly insurmountable. Linking more than a handful of modules results in gcc blowing up... I haven't managed to compile any non-trivial program that uses a decent part of the gerbil stdlib, they all end with the compiler getting OOM killed.
I believe this problem would vanish if the tree-shaker is enabled and the runtime library is refactored to avoid gratuitous dependencies. Then your final executable would only contain the parts of the runtime library (and the program) that are useful for this specific program.
This strategy is what I envision for the universal backend where the bloat is more severe than in C.
The second method is to use the “core” declaration (which is undocumented). When a toplevel definition is in the scope of a (not core) declaration, it will not generate any code per-se, but the definition is remembered so that the definition can be inlined in the rest of the program. For example:
thanks, I didn't know about it; this sounds useful to force inlining of a module in conjunction with the include method. How does it behave with complex recursive functions or functions that are used more than once? Will it emit code for the function then?
No. You still have to separately compile and link the modules. These modules will be compiled to normal function definitions. The modules included in the scope of a (not core) declaration produce no code, but the definitions are available to the inliner.
I think a new form to limit the scope of declarations would be useful for all of this. For example:
(declare (core))
(begin-with-declaration-scope (declare (not core)) (include "mod.scm"))
;; at this point we are back in the scope of the (declare (core))
Maybe begin-with-declaration-scope could have a better name…
Marc