Mark H Weaver <m...@netris.org> writes: > I wrote: >> For now, I will describe a method that I suspect would do the right >> thing without any new compiler interfaces, though not as efficiently or >> robustly: Simply compile the same general-purpose dispatcher as before, >> except replace the #f (from the first case-lambda clause) with the >> expanded local expression: > > Although this should result in the same set of captured lexicals, it > does not necessarily guarantee that the closure slots will be in the > same order. This could be perhaps be solved by always sorting the > captured lexicals by name, but that would slow down the compiler. > Depending on how the compiler works, it might be sufficient to move the > <expanded-local-expression> case to end of the case-lambda, but that's > definitely fragile. > > So, I guess this all shows that `local-eval' really shouldn't be > implemented this way, but rather by creating a new internal interface to > the compiler that ensures that the closure slots are exactly the same as > before. > >> Most passes of the compiler will pretend that (the-environment) is >> replaced by tree-il code corresponding to the following standard scheme >> code: > > I should also mention that perhaps, instead of simply "pretending", it > might make sense to actually replace (the-environment) with the standard > scheme code I gave as early as possible, so that later passes will never > even see `the-environment' tree-il nodes. It need only be late enough > so that the list of visible lexical variable names is known at that > point. > > Apologies for sending multiple messages so quickly. > Obviously this is a work-in-progress :)
And I consider this _very_ exciting work in progress. One of the things that the current development line of GCC markets is "compiler plugins". Here GUILE has an opportunity to offer similar functionality in a natural, Scheme-like manner with little complexity exposed to the user of this feature, and apparently not all that much complexity needed to get added to the compiler: it is more a matter of factoring the complexity that has to be there anyway in a proper way. Which actually might make the compiler code easier to understand und modify even if you don't end up using local-eval. Being able to employ this in Lilypond to simplify things would certainly be a nice side benefit, but this has the potential to simplify and facilitate quite more complex scenarios with simple tools. It would be _much_ _much_ simpler to use than GCC plugins. And the better it integrates with the compiler as a whole, the less reason would be there _not_ to use it whenever it might be useful. -- David Kastrup
