Re: What's the status of modules and macros?

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
> 
> > Syntax-case works by renaming all lexical variables in a special way
> > so that unwanted name-clashes are avoided.  I want to extend this
> > rewriting so that references to top-level variables are `annotated'
> > with the module that they are to be found in.  This could be done
> > with a new special form that is memoized into a gloc.
> 
> So I presume there's a way to ask a reference if it's "top-level".
> (I'll go look a the syntax-case code...)

Yes, the syntax-case transformer knows all of Scheme and keeps a
`compile-time environment' when it traverses the code so that it knows
what identifiers are bound where.  Consequently, it can identify
references to top-level variables inside `syntax' forms.

> Also, I looked up gloc and found it in
> devel/modules/module-snippets.texi.  From that definition I gather
> that it's just a way you can directly access a variable i.e. if a
> variable value was in the cdr of a cons cell, a gloc might just be
> the cons cell.  Is that right?

Yes, more or less.  A gloc is a specially tagges pointer to a vcell,
which holds a value in its cdr and a symbol in its car.  In the
vcell-cleanup branch, glocs are pointers to variable smobs, with the
value in the smob data slot (cell word 1).

I just realized that we don't need to specially tag gloc pointers when
they point to variables since variables can be identified already on
their own (while vcells can't).  That would significantly cleanup the
gloc/struct tag clash magic (which is something that you probably
don't want to know about) since we can use the gloc tag for structs
exlcusively then.

Hmm, I'll experiment with this in the branch.

> So does this replacement (of a reference with a gloc) happen at
> run-time (the first time it's hit) or at macro-expansion time (I
> figure the latter, but just want to make sure I'm developing a decent
> mental model of the process).

Right now it would happen at run-time, at the first hit.
Conceptually, I'd say it should happen at load time, when a body of
code is massaged into the Guile run-time image.

> > If this is used exclusively, all references to top-level bindings
> > are explicit, and we wouldn't need to store the lookup closure at
> > the bottom of the lexical environment.
> 
> Which directon is "up" here?  Is the top-level environment at the
> bottom of the "lookup chain"?  (Just trying to make sure I'm
> understanding right).

Err, yes, with bottom I meant to outermost level of the environment
chain.  The *top*-level, so I shouldn't have said bottom here.

> > The downside to this fix is that it works only with syntax-case, which
> > is still only an optional feature of Guile.  Defmacros could use it as
> > well, but only manually and non-portably, which might well be
> > acceptable.
> 
> Hmm.  It would be nice if we could figure out a strategy that works
> for macros transparently (without having to re-write any that refer to
> module local bits), but I don't have any suggestions right now :>

That would be akin to finding a strategy to making defmacros
transparently hygienic.  If there would be such a thing, we wouldn't
have syntax-case et al, I think.