Thanks for the reply.
Alex Sandro Queiroz e Silva wrote:
I was talking indeed about size. The GHC distribution for Windowsdoes exactly what you suggested. ...
Interesting.
The good applications of this kind let the user enter their own technical indicators (usually in an ad-hoc scripting language) and let the user run them on the previous stock data to see how good they are. Generating a shared object for each run would quickly degenerate in lots of shared objects in the user hard-disk. I know this is fixable, but it's nevertheless an annoyance.
Yep. One idea is to create a hash value of the (expanded) source code s-expression (i.e. the final compiler input) and use that for the file name, so that you never recompile if the input is the same. (And clean up on the basis of atime or randomly.)
I certainly agree that compiling directly to memory may be sensible in such a case. There are things to keep in mind though: if you serialize closures or continuations from such code, you won't be able to deserialize them after a restart of the system (unless you first compile the same code (to memory) again -- or include the assembly code inside the serialization, which you don't really want to do). (This is something also in need of some care with the file based approach (modulesystem...). I just thought I'd mention it here.)
Christian.