Re: [Scheme-reports] ANN: first draft of R7RS small language available

[Alex Shinn <alexshinn@x>]

On Mon, Apr 18, 2011 at 11:48 PM, Andre van Tonder <andre@x> 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.

> 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.

I happen to be the author of Chibi, so I do know a thing or two
about module systems and macros, but that's irrelevant.
Figuring out who knows more isn't interesting to me.  All I'm
concerned with is making the best report possible, and that
requires actually thinking out all the alternatives and
implications of every decision.  If this means I have to play
devil's advocate and ask the stupid questions that no one else
is asking and look like a fool in the process, so be it.

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?

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 I'm going to have to try to provide both sides of
the argument.

As a bit of background, the absolute most important goal in my
opinion is that as many implementations as possible are able to
implement the standard and write and share modules.  I'm willing
to sacrifice features in the standard if it means more
implementations can be supported, so long as it doesn't
_prevent_ those features from being implemented in a robust
implementation.  This is why the module system is deliberately
vaguely specified.

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.

And if we don't bind the keywords:

(2)

  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: Must rename any imported identifier that conflicts with a
  keyword (i.e. keywords you use must always stay unbound).

  Con: Chez may have to violate the standard on this point and
  bind the keywords anyway (with various ugly repercussions), or
  possibly match them unhygienically.

Of course, in neither case can you portably rename keywords.
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.  If we don't require
imported bindings to match, I think the only sane thing is to
leave the standard keywords unbound.  Robust implementations of
course will make imported bindings match anyway, and may take
advantage of this in their own modules.

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.

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).

So (1) is not even an option, and both (2) and (3) pose problems
for some implementation techniques, so without weighing the pros
and cons too heavily (4) stands out as possibly the safest
option.  It doesn't prevent more robust implementations from
binding other keywords in non-standard modules, but if they want
versions of cond, case, etc. which refer to bound (and thus
renamable) bindings, they would have to provide them in a
separate module.

On the other hand, implementations for which (3) is a problem
may not be worth supporting.  That's a statement I'm _very_
hesitant to make, and some of the implementations we want to
target don't have module systems and/or hygienic macros at the
moment, so I want to look into this a little more.

-- 
Alex

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