[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: structures at expansion time



--- Matthew Flatt <mflatt@cs.utah.edu> wrote:
> You might mean either of two things:
> 
>  1. your macro generates in instance of the structure, or
> 
>  2. your macro generates an expression that instantiates the
> structure.
> 
> #1 doesn't work. #2 does.
> 
> [snip programs ...]
> 
> I'm guessing that you have a program like the original one, and you
> want
> a program like the revised one.

You're right. I was keeping a list of structures, evaluated when the
define-syntax form was produced, not when it was evaluated.

> [...]
>
> > However, it seems that the structure definitions are re-evaluated
> > every time the core module is required, so information built in
> one
> > module cannot be accessed by another (because the accessors don't
> > match the right structure type).
> 
> It's not every time the module is required; but a
> required-for-syntax
> module is invoked every time is is used to expand a different
> module.
> 
> Thus, in the example above, `s' is invoked once to expand `a', and
> again to expand `b'. The revised example works because the
> expansion-time portion of `a' is also executed afresh when `b' is
> expanded (so the `make-d' call happens again as `b' as expanded,
> not
> just once as `a' is compiled).

I was initially confused about what "phases" referred to in the HTUS
modules chapter. I thought only require-for-syntax separated phases.
Then once I understood that the expansion-time part was being
re-evaluated, I only saw it as a restriction and not as an
opportunity. Thanks for clearing that up.

Is this picture right? An expanded module's contents can be separated
into two portions: define-syntaxes forms and everything else. The
define-syntaxes part of every module is re-evaluated whenever the
module is required. Everything else is only evaluated once at runtime
and once per require-for-syntax. 

> > While I think I understand why the module system works this way
> (to
> > make separate compilation consistant?),
> 
> Right. It's all designed to make you post to plt-scheme now,
> instead of
> much later when you're trying to push the code through mzc. :)
> 
> (The plt-scheme post, in turn, helps me figure out how to better
> explain and document things.)

I did try pushing it through mzc. :) (In the end the macros are
producing c-lambda forms.) Neither my code nor the unmodified program
you gave would compile: INTERNAL ERROR: vm:build-constant: not
supported #<struct:zread>.

Thanks,
Ryan



__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/