Andy Wingo <wi...@pobox.com> writes: > On Wed 14 Dec 2011 08:50, Mark H Weaver <m...@netris.org> writes: > >> I have successfully implemented the (capture-lexical-environment) >> special form in the evaluator, and also primitive-local-eval. > > I dunno, Mark. That's a neat hack, but why should we have it in Guile? > It can't compile. It's not for efficiency, because if you wanted more > efficiency, you would compile.
Most of the multi-list commands in srfi-1 have awful performance implications once you give them more than a single list. And you can usually create more efficient equivalent code manually for most non-generic uses of them. So they are obviously not in there for efficiency, but rather feature completeness and user friendliness. > So what is it for? It has a cost, so it needs to justify itself. It is a trade-off. The reason to include it in Guile rather than providing it as an external package is because it depends on internals of Guile, and thus needs to be maintained along with it. Is the expected cost of maintenance worth the gain in Guile's attractiveness? A more thorough solution that would actually cooperate with the compiler would likely be more attractive, and more prone to maintenance. But it would also likely serve to hold open the architecture for future developments or plugins that could be interesting for integrating Guile into other language systems like Emacs Lisp (which is only very slowly moving towards lexical bindings) or Lua or other binding-intensive systems. Language interfaces that are not strictly ad-hoc and closed-door would certainly help in keeping Guile interesting for applications where the respective maintainers don't have to count on the continued cooperation of Guile developers, but merely on the continued existence of published interfaces. I can't judge the best trade-off point here. Nor how complex it would be to actually work with the compiler, and be reasonably confident that it will continue to work without too much hassle in future. But an outside package meddling with undocumented internals is not safe to rely on at all. It can break at any point of time with no active Guile developer being in a position where he would feel compelled to fix it for the sake of Guile. -- David Kastrup