Re: (set! (@@ MOD NAME) EXP) considered harmful

[Andy Wingo]

Hi Mark,

On Wed 02 Sep 2009 18:17, Mark H Weaver <address@hidden> 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/