This is the mail archive of the email@example.com mailing list for the guile project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
> A sealed module system would definitely help to optimize a lot, but I > think reaching Stalin-level optimizability would require even more > changes, some of which may be in conflict with Guile's useful dynamic > properties. For instance, I think the feature of importing or creating > a module at runtime is very useful - it can be used to isolate > untrusted code for instance. But it also conflicts with some smart > optimizations. It might but it doesn't have to. What is necessary is that every time you do runtime module fiddling it is visible to the compiler. In principle, scheme supports self-modifying code by using things such as load and eval. Languages like C say outright that they give no support to self-modifying code (which doesn't stop people!) but no compiler can hope to support self modification in a generic way so any trace of self-modifying code (and I believe that this includes creating modules at runtime) might potentially spoil compilation. The answer is not to outlaw anything self-modifying but to ensure that the compiler can detect it and either refuse to compile, reduce its level of optimisation or possibly just partially compile the module. You don't want people finding back-door ways into the module system but there is no harm done if they march in the front door and admit that they are doing something that might not compile. This is another reason for my idea about a guile storage library existing as a separate entity to the evaluator. Some programs may compile to run without the evaluator but still make use of the storage library. These programs would then be more ``lightweight'' and good for distribution, quick execution, embedded systems, etc. The compiler should be able to decide whether a given piece of code needs to link with the evaluator library or just the storage library. - Tel