Hi Mark, On Wed 02 Sep 2009 18:17, Mark H Weaver <m...@netris.org> writes:
> The ability to set! arbitrary module top-level variables from outside > the module, using the syntax (set! (@@ MOD NAME) EXP), destroys our > ability to several important optimizations. > > As long as such ability exists, we must pessimistically assume that > any module top-level variable might change at any time, which means, > for example, that we cannot inline top-level procedure applications > from within the module itself. This could be a HUGE efficiency win in > the common case where such top-level procedures are never set! from > within the module. I disagree, heartily. Guile is a dynamic system, one where you can get into modules and redefine functions. All you have to do is (set-current-module! (resolve-module '(foo))) and (define bar #f) to do the equivalent of (set! (@@ (foo) bar) #f). It's just like that. And we should be proud of that, IMO! Your program might be a reified gem once you're finished with it, but it normally doesn't arrive there without much debugging. Furthermore, (set! (@ ..) ..) is a /consequence/ of hygiene. A hygienic macro that expands out to a set! of a variable in its context will compile to a (set! (@@ ...) ...). You can always get at the module-private vars, even with hygienic systems -- see the eval-in-module hacks from ikarus if you don't believe me there. Now, regarding optimizations. We can optimize whatever we like ;) More seriously, there are many possibilities there. One is to define your modules in lexical forms, as Chez does it -- so private functions will always be inlined. See the end of section 2.4 on http://www.scheme.com/csug7/use.html. Another is to always present module-private bindings as candidates for inlining. Another is to allow the user to mark certain procedures as inlinable. That will certainly be the case with `map', for example. Another is to have an optimization knob you can crank up, understanding that higher levels of optimization prevent some runtime modifiability. In short, @ and @@ are lovely and useful, and we should be happy with them. (set! (@@ ...) ...) is not an expected operation from user code, and may reasonably be discounted even at low optimization levels. I don't see the problem :) Andy -- http://wingolog.org/
