Mark H Weaver:
> I think this new draft is very promising.  However, there's still one
> major piece missing: a description (in english) of what data structures
> are created.  Somehow that needs to be integrated into this new text.

I'm not sure I understand.  If by "data structure" you mean
n-expressions, those are already defined in SRFI-105.
It's really just s-expressions with a few tweaks.

> There's still a remnant of that in the SUBLIST bullet item, but it still
> uses the unclear terminology of the RHS becoming the "last parameter" of
> the LHS.  That entire bullet item is still unclear to me.
>
> I still don't know what it means for "<A> to be made the last parameter
> of <B>".  Even if I did, I don't like the use of "parameter" in the
> description of a datum reader.  I'm glad that you tried to clarify what
> the RHS is ("including all child lines"), but it's still not clear how
> the RHS is converted into a datum.  The LHS is still mysterious to me.
> Does it include parent lines?  How is it converted into datum(s)?
>
> So IMO, you should find a clearer way to describe in english how these
> syntactic elements are converted into datums, and then you should
> integrate such descriptions into the whole of the "Basic specification",
> so that all of the rules are covered.

I'm open to ideas!

> I think that most readers will find the BNF quite intimidating, so it
> would be good if casual readers could obtain a reasonably clear
> understanding of the rules without reading the BNF.

I tried to do that earlier, and the rewrite tries to do that a little bit.

Suggestions?

> This new text is a great start,
> but IMO it needs to include an english description of the
> action rules as well.

I don't think that would help.

> Other than that, just a few minor points:
>
> * 'eol sequence: [...] (short for "horizontal space")'
>   I guess that "horizontal space" is a mistake, no?

Whups!  Fixed.

> * "simplifying simplifies" => "simplifying"

Fixed.

> * Re: "leading traditional abbreviation (quote, comma, backquote, or
>   comma-at)": IMO, for readers that support the syntax-case
>   abbreviations (#' #` #, #,@), I think that it ought to be _mandatory_
>   for these to be handled in the same way as for (' ` , ,@).

I disagree. Many Scheme systems do not implement them or
implement some of these with very different semantics.
For example, the many Schemes that implement SRFI-10
do something completely different with "#,".
They've also been abandoned in R7RS.

A particular Scheme implementation is certainly *welcome* to
implement them, but those constructs are not portable to R5RS
or R7RS without sweet-expressions... this just continues the
status quo.

--- David A. Wheeler