On Tue, 19 Apr 2011, Alex Shinn wrote:

> On Mon, Apr 18, 2011 at 11:48 PM, Andre van Tonder <andre@het.brown.edu> wrote:
>>
>> As someone who has implemented the R6RS macro and module system
>> (in a form of explicit renaming system no less), it is clear to me from
>> this and other remarks that you and perhaps others on the WG don't
>> quite appreciate the technical ins and outs of implementing macros
>> and modules in a mutually consistent way.
>
> Sigh.  It's amazing how quickly Schemers resort to argument from
> authority.

That was not my intention, and I'm sorry you took it that way.  My intention was
to point out how I and others got pie in our face many times as far as our
preconceptions were concerned when we actually implemented the stuff, and to
point out that implementation of several different approaches to macros and
modules during R6RS forced us to backtrack and modify our ideas several times.

I certainly don't think of myself as some big authority.  I am just seeing you
go through some of the same iterations that we did, and it was
in this spirit that my suggestion was offered.

>> I would therefore STRONGLY advise that, before you continue work
>> on the module and macro system, you do a reference implementation
>> first and foremost.
>
> As announced in the post, Chibi is a reference implementation of
> the entire report (modulo some naming, and also modulo the I/O
> system which is still under minor contention, but was taken
> directly from Gambit).  We considered proof of implementability
> essential before deciding on anything.

One reference implementation is not enough.  Let me just point out that for R6RS
three different implementations of macros and modules were done - Chez and PLT
based on versions of the psyntax algorithm, and the Larceny system based on a
modification of explicit renaming.

It was important not just to find one proof of existence and adapt it, but to
find a common denominator that also took into account the prior art.

> We're getting lost in the details on the individual points, and
> they pretty much all hinge on the one real question - are
> imported values required to be the "same" binding in terms of
> the syntax-rules pattern language?

No, this has nothing to do with the question of keywords.  In Chez and Larceny,
they are the same binding.  In the PLT system they were not - new bindings were
created upon import in many cases (i.e., the module was reinstantiated more
than one time), yet both systems were able to bind, import,
and export keywords as I advocated.

> This is http://trac.sacrideo.us/wg/ticket/157, so we'll be
> voting on it in the next ballot.  If it really is so obvious
> then giving a reason should have been easy.  Since you didn't
> give a reason

Good grief (hitting head against wall).  I gave many reasons, that apparently
fell into a black hole.  Can you see why I have been getting frustrated?

> So given this status quo, we can consider the pros and cons of
> binding keywords:
>
> (1)
>
>  Pro: In some cases it may be possible to provide earlier or
>  more descriptive error messages.
>
>  Con: You need to import all of the keywords used, and list
>  them explicitly if using "only".
>
>  Con: Keywords aren't guaranteed to actually match outside of
>  the (scheme) module.

This con is incorrect.  It can be a con if you DON'T bind the keywords in some
systems, not if if you DO bind them.  If you bind them, they MUST match if your
macro system is correctly implemented.  This is a simple question of lexical
scoping, which is fundamental in Scheme.  In

(module (A)
   ...
   (define counter (let ((n 0)) (lambda () (set! n (+ n 1)) n)))
   (define-syntax counter-macro (syntax-rules () ((_) (counter))))

(module (B)
   (import (only (A) counter counter-macro))
   (write (counter-macro))
   (write (counter)))

THIS MUST PRINT 1 and 2, OTHERWISE LEXICAL SCOPING IS BROKEN.  Are you telling
me that Chibi has broken lexical scoping?  In any case, with this whole
discussion you are basically advocating accomodating systems whose
implementation of lexical scoping is so broken that they would instead print 1
and 1.  I don't think a standard should bother to accomodate broken
implementations just because it seems easier (which it is not, by the way).

> Of course, in neither case can you portably rename keywords.

This is completely incorrect. In all of R6RS Chez, R6RS Larceny, and R6RS PLT,
keywords are bound and you can portably rename them.

> There are some interesting points on both sides, but the
> "keywords aren't guaranteed to match" issue is pretty damning
> and basically breaks R5RS compatibility.

To repeat, this point is moot.  In all of R6RS Chez, R6RS Larceny, and R6RS PLT,
keywords are bound AND GUARANTEED TO MATCH CORRECTLY.  And to repeat, this does
not dpend on some vagaries of Psyntax, since Larceny's system is basically
explicit renaming.

> If we don't require
> imported bindings to match, I think the only sane thing is to
> leave the standard keywords unbound.

If you don't require imported bindings to match, then you are breaking lexical
scoping, as I already pointed out above.

> Robust implementations of
> course will make imported bindings match anyway, and may take
> advantage of this in their own modules.

If by "robust" you mean "with correct lexical scoping", I fail to see why you
should accomodate incorrect implementations in the standard.

> You weren't even considering this scenario, so let's look at
> what happens if we require imported bindings to match.  First,
> the pros and cons if the keywords are bound:
>
> (3)
>
>  Pro: In some cases it may be possible to provide earlier or
>  more descriptive error messages.
>
>  Pro: You can rename keywords.
>
>  Con: You need to import all of the keywords used, and list
>  them explicitly if using "only".
>
>  Con: Some simple implementations may need to violate the
>  standard and leave the keywords unbound (with various ugly
>  repercussions), or possibly match them unhygienically.

Again, why would you bother accomodating systems that have incorrect lexical
scoping?  They have bigger problems anyway.

> and if they are unbound:
>
> (4)
>
>  Pro: No need to import keywords explicitly.
>
>  Pro: Multiple unrelated modules can use the same keyword, and
>  both of those modules can be used by a third-party module
>  without needing to rename the keywords.
>
>  Con: May lose some opportunities for earlier or more
>  descriptive error messages.
>
>  Con: Can't rename keywords.
>
>  Con: Must rename any imported identifier that conflicts with a
>  keyword (i.e. keywords you use must always stay unbound).

This last one is a pretty serious con.  If a user violates a conflict, the
program will fail silently.

> So (1) is not even an option, and both (2) and (3) pose problems
> for some implementation techniques,

Which implementation techniques?  I am curious, becasue I believe they all would
violate lexical scoping.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports