[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new-model.text, please comment
From: |
Marius Vollmer |
Subject: |
Re: new-model.text, please comment |
Date: |
13 Sep 2002 22:22:03 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Rob Browning <address@hidden> 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
- new-model.text, please comment, Marius Vollmer, 2002/09/11
- Re: new-model.text, please comment, Rob Browning, 2002/09/12
- Re: new-model.text, please comment,
Marius Vollmer <=
- Re: new-model.text, please comment, Neil Jerram, 2002/09/13