[r6rs-discuss] Problems with import syntax

From: R. Kent Dybvig <dyb>
Date: Wed, 27 Jun 2007 21:20:01 -0400

> 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
Received on Wed Jun 27 2007 - 21:20:01 UTC