[plt-scheme] require-for-syntax issues

From: Felix Klock's PLT scheme proxy (pltscheme at pnkfx.org)
Date: Thu Jul 10 12:01:54 EDT 2003

On Thursday, July 10, 2003, at 11:26  AM, Matthew Flatt wrote:
> [...]
> Suppose that you want the #'id produced by `helper' when called by `s'
> to have run-time bindings from more-utils. It would be best if you
> could write something like this:
>
>  (module utils mzscheme
>    (require-for-next more-utils) ;; imports phase -1 bindings
>    (provide helper)
>    (define (helper) #'id)
>            ;; #'id has run-time bindings (phase 0) from mzscheme and 
> utils,
>            ;; elaboration-time bindings (phase 1) from mzscheme
>            ;; and next-time bindings (phase -1) from more-utils.
> 	   ;; Shifting by +1 puts more-utils bindings in phase 0
>    )
>
> But `require-for-next' doesn't exist. We're trying to add it.

Hmm.  Some comments:

1. 'require-for-next' seems like a somewhat unintuitive name; after 
all, require-for-syntax is not called 'require-for-previous'; have you 
considered alternatives like 'require-for-runtime' ?  [Where one 
assumes (perhaps demand?) that this module will be imported using 
require-for-syntax...]  I can understand the reasoning behind the name 
'require-for-next', in terms of syntactic towers, but the other names 
don't make such explicit references to the tower, which makes the 
naming convention inconsistent.

2. Are you sure that you want to put the require-clause for the runtime 
bindings into the syntax-providing module [utils in this case] ?  Would 
a sensible alternative be to add a new kind of clause to 
require-for-syntax that indicates what module, if any, should provide 
the phase 0 bindings after the upward shift?  To continue your example, 
the code for the module m would look like:

(module m mzscheme
    (require-for-syntax (with-runtime more-utils utils))
   ;;; This require-for-syntax instantiates utils at elaboration time, 
shifting its bindings by +1 phase,
   ;;; AND getting run-time bindings (phase 0) from more-utils.

    ;;; as an aside, I'm not sure if you intended in your example to 
still require m to import more-utils;
    ;;; it seems redundant if m doesn't reference anything in more-utils 
itself...
    (define-syntax (s stx) ... )
)

I actually haven't made up my mind as to whether this with-runtime idea 
is preferable to require-for-next... and of course I have no idea as to 
the relative difficulty of implementing each approach.

I guess the sticking point for me is that require-for-next only makes 
sense when the module is imported using require-for-syntax; if you're 
going to have that dependency, does it make more sense to put the two 
pieces together?  [an honest question; maybe both approaches are worth 
adding, if we can figure out a sensible way for them to interact]



-Felix, who is starting to appreciate why MIT went with 
syntactic-closures (with explicitly denoted lookup environments) for 
its macro system.



Posted on the users mailing list.