[R6RS] more import-syntax changes

[R. Kent Dybvig]

I've just made the two changes noted below---look for "Right".  (The
second is actually backing out an earlier change.)

Kent

--------

> From r6rs-discuss-bounces at lists.r6rs.org  Wed Jun 27 21:20:42 2007
> From: "R. Kent Dybvig" <dyb at cs.indiana.edu>
> Date: Wed, 27 Jun 2007 21:20:01 -0400
> To: r6rs-discuss at lists.r6rs.org
> Subject: Re: [r6rs-discuss] Problems with import syntax
> List-Id: R6RS discussion <r6rs-discuss.lists.r6rs.org>
> X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
>
> > What I was suggesting was to go further: make (LIBRARY ...) mandatory.
> > If LIBRARY was not optional, there would be no ambiguity to worry about,
> > and the complicated parsing rules, and requirement of non-empty degenerate
> > cases, could be dropped.  Import statements
> > would become a little longer, but much more readable, and we could be
> > sure that no remaining ambiguities will bite us unexpectedly.
>
> The common cases may not be more readable.  In any case, this is more of a
> change from 5.93 than I feel comfortable with, since we lack time for
> feedback on such a requirement.  An optional (library ---) import set
> syntax is less likely to cause displeasure than a required one.
>
> > Yes, but I believe you left out "for".  How about "and", "or" and "not"?
> > I do not like the following:
>
> Right, thanks.  "for" should be included.  I don't think it's necessary
> to include "and", "or", "not", etc.
>
> > > Also, although not noted among the changes, the "and" and "or" import
> > > syntaxes can no longer be empty, and the "except", "only", and "rename"
> > > forms can no longer list zero identifiers or identifier pairs.  As has
> > > been noted, these degenerate cases contributed to the ambiguity problem
> > > and they serve no useful purpose.
> >
> > I think this is unnecessary, since I believe this could help disambiguate
> > only if we allow the meaning of surrounding forms to depend on inner forms,
> > i.e., for meaning to be determined from the inside and not the outside.
> >
> > It would also be very unfortunate to complicate the syntax this way. 
> > Degenerate cases make syntax checking and parsing easier, not to mention 
> > automatic code generation.  Also, if you forbid 0-argument AND, why allow 
> > 1-argument AND, which is equally unnecessary?
>
> Right again.  This change should not have been made, especially since it's
> a bigger change than necessary from 5.93.
>
> > All in all, there are still hairy cases:  For example, with your suggestion 
> > above, what am I to make of these, in the light of your suggestion:
> >
> >    (import (for))                as opposed to
> >    (import (for (and)))          as opposed to
> >    (import (for (and (1))))
>
> I believe that including "for" along with the others as you suggested
> above disambiguates these cases.  That is, the first is invalid syntax,
> while the second imports library (and) for no phases, and the third
> imports library (and (1)) for no phases.
>
> > Even if we can plug all the holes as far as disambiguation is concerned,
> > it is an ugly mess.  And even if we manage to seal off all the ambiguities, it 
> > is getting to the point where I would not trust myself to implement the whole
> > complicated mess correctly.  The simplest and only watertight solution, IMO, is 
> > to make (LIBRARY ...) mandatory.
>
> I don't believe what we're converging upon is difficult to implement.  It
> is posible we haven't sealed off all ambiguities, but if they are of the
> nature of the ones that have already come to light, I doubt they'll cause
> trouble in practice.
>
> > > A majority of the editors are in favor of retaining versions, so I don't
> > > expect this to happen before our adoption candidate is released.
> >
> > Even if versions are kept, there were issues about the granularity
> > of >= and <= (if they act on subversions as opposed to versions, they
> > cannot easily express ranges), and other issues raised by others, that
> > would be nice to have improved from the current situation.
>
> The current version syntax may not be convenient for all versioning
> practices, but that is probably true of any version syntax.  In any case,
> we don't have time to come up with a perfect one in the next couple of
> days, so our choice is between including the version syntax or not.  While
> I'm rather ambivalent about the version syntax, others feel strongly that
> it should be included, and ripping it out at the last minute might make
> more people unhappy than happy.
>
> Thanks again for your feedback.
>
> Kent
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>