[plt-scheme] require-for-syntax issues
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.