[r6rs-discuss] Problems with import syntax
> 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>.
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.
> The spec also says:
>
> The syntax of an <import spec> is interpreted outermost to innermost if
> ambiguities arise.
>
> This could be dropped if the above suggestion is adopted, in which case the
> syntax would be unambiguous.
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.
> I am still hoping, though, that versions will
> be dropped or simplified, in which case LIBRARY will not even be necessary.
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.
Kent
Received on Wed Jun 27 2007 - 16:01:34 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC