[plt-scheme] Inlined language from a language module

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Mar 20 18:33:49 EDT 2009

At Fri, 20 Mar 2009 17:50:09 -0400, Sam TH wrote:
> > The problem is that `strip-context' removes the lexical context that
> > includes `require's --- even the `require's introduced by
> > `syntax-local-lift-require'.
> 
> At first I thought I understood what you meant here, but on further
> reflection, I can't figure it out.  If `strip-context' removes the
> context from the expr such that it can't find the `require', then why
> does the original implementation work?  Ryan's hypothesis was that the
> module top-level restores the relevant context, but then this should
> work:
> 
> [...]
> 
> when used at module-top-level.  But it doesn't - it fails with the same error.
> 
> Can you explain what's going on here in a little more detail?

The missing detail is that `require's are collected in two places. One
corresponds to the original module body, and a second corresponds to
macro-introduced `require's.

The second place is also applied to the expansion of a top-level form
in a module body, so that's why expanding to `(begin (require ...)
...)' works. Macro-introduced definitions are added to the same place,
which is why the similar form

   (begin
    (define x 10)
    x)

as a macro-expansion result works; the second `x' sees the defined `x',
it gets the post-expansion set of renames.

A `syntax-local-lift-require' adds to renamings to the first place (for
the original module body), instead. This choice is specifically to
prevent your exampling from working, so that it's consistent with
expansion in a nested expression.


Probably `syntax-local-lift-require' would be more useful if it added
the renamings from the `require' to its second argument. In general,
the current representation of syntax objects cannot encode such a local
renaming, but expanding that representation might be the right next
step.



Posted on the users mailing list.