Hi David,

"David A. Wheeler" <xxxxxx@dwheeler.com> writes:
> Here's a try at rewriting the spec.  Basically, I tried to introduce
> some definitions, and then drop to the BNF to actually define things.
> I tried to steal some of the approach from SRFI-49, since that was
> previously accepted.
>
> Is this a better way to proceed?  Comments?

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.

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 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.  This new text is a
great start, but IMO it needs to include an english description of the
action rules as well.

Other than that, just a few minor points:

* 'eol sequence: [...] (short for "horizontal space")'
  I guess that "horizontal space" is a mistake, no?

* "simplifying simplifies" => "simplifying"

* 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 (' ` , ,@).

     Thanks!
       Mark