[R6RS] more import-syntax changes
R. Kent Dybvig
dyb at cs.indiana.edu
Wed Jun 27 21:39:29 EDT 2007
I've just made the two changes noted below---look for "Right". (The
second is actually backing out an earlier change.)
> 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.
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
More information about the R6RS