[r6rs-discuss] Problems with import syntax

From: AndrevanTonder <andre>
Date: Wed, 27 Jun 2007 17:08:41 -0400 (EDT)

On Wed, 27 Jun 2007, R. Kent Dybvig wrote:

>> I think the LIBRARY keyword is in the wrong place. I believe that,
>> to eliminate ambiguities, it should be part of <library reference>, /not/
>> <import set>.
>
> (library <library reference>) was supposed to be an <import set>, which I
> think is equivalent to what you are suggesting. Otherwise one cannot use
> the library form for disambiguation within an <import set>.

I see, right now it is above at <import spec> - I assume it should not be
there, and by the way (related), the draft
specification of <import spec> presumably incorrectly says that

  (library <library reference>) is synonymous to <import set>.

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 point of this was to avoid requiring implementations to backtrack to
> resolve ambiguities, including those that can arise if a programmer
> chooses not to use the "library" form, but it's confusing and probably
> doesn't achieve the goal. I propose to replace this with the following
> requirement:
>
> A <library reference> whose first <identifier> is "library", "only",
> "except", "prefix", or "rename" is permitted only within a "library"
> <import set>. The <import set> (library <library reference>) is
> otherwise equivalent to <library reference>.
>
> I believe this accomplishes the intended goal more simply.

Yes, but I believe you left out "for". How about "and", "or" and "not"?
I do not like the following:

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

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

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.

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

Andre
Received on Wed Jun 27 2007 - 17:08:41 UTC