Re: new-model.text, please comment

[Marius Vollmer <mvo@zagadka.ping.de>]

Rob Browning <rlb@defaultvalue.org> writes:

> > The compiler is free to reuse top-level frames for several top-level
> > forms, even when executing a form will change the name/module mapping
> > used in the next.  You must explicitely tell the compiler that it must
> > construct a new top-level frame.  You can do this with the
> > 
> >   (:module-barrier)                       XXX - need better name
> > 
> > compiler directive.  The directive guarantees that code prior to it is
> > fully executed before top-level frames for forms after it are
> > constructed.  The directive must be a top-level form.
> 
> Could you provide a bit of elaboration here.  More specifically, what
> does "fully executed" mean?

There is no special meaning to "fully" here.  I could have just said
"executed".

> For example, does the above mean that given the following code:
> 
>   (foo ...)
>   (do-something-that-changes-the-current-module!)
>   (bar ...)
> 
> the results would be undefined because the compiler is within its
> rights to presume that do-something *doesn't* change the current
> module unless a without a :module-barrier call like so:
> 
>   (foo ...)
>   (do-something-that-changes-the-current-module!)
>   (:module-barrier)
>   (bar ...)
> 
> This seems to be implied by the later examples of use-modules, etc.,
> but I just wanted to make sure I understood what you were stating.

Yes, this is what I had in mind.  Without this :module-barrier
statement, the compiler would have to assume that any call can change
the module setup (which will make a lot optimizations impossible).  Or
we would have to have a different kind of module system.

We could have also use declarations to communicate the module barrier
to the compiler.  I.e., the variable named
do-something-that-changes-the-current-module! has a declaration that
the compiler understands.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel