This page is part of the web mail archives of SRFI 62 from before July 7th, 2015. The new archives for SRFI 62 contain all messages, not just those from before July 7th, 2015.
On Mon, 10 Jan 2005, Alpert Herb Petrofsky wrote: > >From draft 1.1: > > > -- Specification -- > > > > A new octothorpe reader syntax character is defined, #\;, such that > > the reader ignores the next S-expression following it. For example, > > > > (+ 1 #;(* 2 3) 4) => 5 > > (list 'x #;'y 'z) => (X Z) > > > > An `S-expression' is defined as a full expression that READ may > > return. > > That's a nice start at an informal specification, but, as the > questions about nesting and spacing have already shown, you need to > elaborate more, Yes, I already put elaboration in the next revision to go up. (I ought to have put it up sooner, I suppose.) > and you need a formal specification too, in BNF, as in > r5rs. OK, I'll add that in the next revision, too. (I wrote the initial draft in haste. Why I did that I don't remember, but that accounts for the lack of formality, which will be fixed soon.) > In the "Implementation" section, you only provide four lines of code, > which only make sense if you read the much larger section of text > above them, and which only constitute an actual implementation if you > combine them with the entire scheme48 read system, which I doubt is > formally specified anywhere. It was not intended to be an actual implementation (except to Scheme48) -- it was intended to be a suggestion for how most S-expression parsers could implement it. For that purpose, I think it suffices. > That's helpful to scheme48 users, but why not also write an actual > READ procedure that anyone can run against the given examples and > against any examples they think of about which they have questions? > It doesn't take a lot of code to do so in r5rs scheme: see the SRFI-38 > reference implementation (which is only 223 lines, and that includes > numbering stuff you needn't bother with). I planned on later including the rest of Scheme48's reader, which is very simple to begin with (though not as minimalist as SRFI 38's), for a complete example implementation that people can run easily. > I suggest adding these two examples to the srfi, because they test two > of the unusual states of a reader implementation (the after-the-dot > state and the after-the-dot-and-the-following-sexp state): > > (a . #;b c) > > (a . b #;c) OK, I'll add them. The results, for any impatient readers of this mail, are the pairs (A . C) & (A . B). In response to all of the hubbub regarding nested S-expression comments, I have to wonder: how often do you write such nestings? Does it really make so much of a difference that you consider 'fixing' a slightly non-intuitive yet not very common use of S-expression comments more significant than fundamentally changing Scheme's syntax to be sensitive to whitespace tokens? Is it really so significant as to warrant inhibition of simple recursive-descent S-expression parsers?