[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: First impressions of the specification
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.
> 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?
> * "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 (' ` , ,@).
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
--- David A. Wheeler