[plt-dev] syntax/module-reader and #%module-begin

On Tue, Dec 1, 2009 at 11:58 AM, Eli Barzilay <eli at barzilay.org> wrote:
> On Dec  1, Sam TH wrote:
>> On Tue, Dec 1, 2009 at 11:29 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> > On Dec  1, Sam TH wrote:
>> >> On Tue, Dec 1, 2009 at 10:59 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> >> > On Nov 30, Stevie Strickland wrote:
>> >> >>
>> >> >> I've tried making the following change (surrounded by -----):
>> >> >>
>> >> >> -----
>> >> >> Index: collects/syntax/module-reader.ss
>> >> >> ===================================================================
>> >> >> --- collects/syntax/module-reader.ss  (revision 17113)
>> >> >> +++ collects/syntax/module-reader.ss  (working copy)
>> >> >> @@ -170,7 +170,11 @@
>> >> >>                                          (- (or (syntax-position modpath) (add1 pos))
>> >> >>                                             pos)))
>> >> >>                            v))]
>> >> >> -           [r `(,(tag-src 'module) ,(tag-src name) ,lang . ,body)])
>> >> >> +           [wrapped-body (let ([wrapped `(#%module-begin . ,body)])
>> >> >> +                           (if stx?
>> >> >> +                               (datum->syntax #f wrapped all-loc)
>> >> >> +                               wrapped))]
>> >> >> +           [r `(,(tag-src 'module) ,(tag-src name) ,lang ,wrapped-body)])
>> >> >>        (if stx? (datum->syntax #f r all-loc) r)))
>> >> >>
>> >> >>    (define (wrap lang port read modpath src line col pos)
>> >> >> -----
>> >> >
>> >> > Isn't it better to do the wrapping only when `#%module-begin' is not
>> >> > there?
>> >>
>> >> What would this mean?  Looking for the symbolic name
>> >> '#%module-begin?
>> >
>> > Yes.
>> >
>> >
>> >> That seems like it adds another special case, where the benefit of
>> >> the change is to remove such special cases, especially since it
>> >> wouldn't help if you wrote #%plain-module-begin instead.
>> >
>> > It is already a special case -- it's a symbolic name that gets added.
>>
>> Right, but currently the rule for #%module-begin insertion is
>> complicated.  With this change, it would become simpler - if you use
>> #lang, #%module-begin is always inserted.  With your suggestion, the
>> rule grows a special case.
>
> It's not *that* special -- if you use `#lang', the result will get a
> `#%module-begin' unless it has one.

Right, it's not as complicated as the current rules, but more
complicated than the rule Stevie proposed.

>> > (IIRC, `#%plain-module-begin' is not a special case, and intended
>> > only to be provided from a language as `#%module-begin'.)
>>
>> No, you can certainly write
>>
>> (module m scheme (#%plain-module-begin 'x 'y 'z))
>>
>> Thus, if you wanted to support that with #lang as well, you could
>> add the symbol '#%plain-module-begin to this special case as well.
>
> Oh, right -- but I think that that happens only after bindings are
> resolved.

I don't know what you mean by that.  The #%plain-module-begin in the
program I wrote has no bindings until they're provided by `scheme'.

> At least it looks like that, since the C code doesn't have
> any mention of `#%plain-module-begin'.

`#%plain-module-begin' from `scheme' is just the `#%module-begin'
identifier from '#%kernel.

> Also, this works:
>
>  (module fooish scheme
>    (provide (rename-out [#%module-begin foo]) (all-from-out scheme)))
>  (module bar 'fooish (foo 1 2 3))
>
> If this is the case, then module readers should definitely not try to
> deal with anything other than `#%module-begin' since that involves
> more than context-less identifiers.

Right, that's exactly the same thing that's happening with
`#%plain-module-begin'.  All I'm saying is that it's not obvious where
to draw the line at special cases.  For example, we could just say "if
you have exactly one form, don't wrap", and then we're back exactly to
the current system.

>> > The reason I've asked this is that a reader that adds
>> > `#%module-begin' will be broken if it's added by
>> > `syntax/module-reader' unconditionally.
>>
>> That is a potential problem.  Are there any languages that do that
>> right now?
>
> I don't know -- that's (part of) my question.

If there are, and they're hard to fix (ie, on planet), then I think we
should adopt your suggestion.  Otherwise, we should keep the rule
simple.
-- 
sam th
samth at ccs.neu.edu