Formal spec; implementation; nesting Alpert Herb Petrofsky (11 Jan 2005 21:03 UTC)
|
Re: Formal spec; implementation; nesting
Bradd W. Szonye
(11 Jan 2005 21:19 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(11 Jan 2005 22:29 UTC)
|
Re: Formal spec; implementation; nesting
Taylor Campbell
(12 Jan 2005 00:10 UTC)
|
Re: Formal spec; implementation; nesting
Bradd W. Szonye
(12 Jan 2005 00:13 UTC)
|
Re: Formal spec; implementation; nesting
Bradd W. Szonye
(12 Jan 2005 00:16 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(17 Jan 2005 03:03 UTC)
|
Re: Formal spec; implementation; nesting
Alpine Petrofsky
(12 Jan 2005 00:22 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(12 Jan 2005 01:45 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(12 Jan 2005 02:18 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(12 Jan 2005 14:11 UTC)
|
Re: Formal spec; implementation; nesting
Paul Schlie
(12 Jan 2005 14:29 UTC)
|
>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, and you need a formal specification too, in BNF, as in r5rs. 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. 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 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) > Date: Mon, 10 Jan 2005 17:14:56 -0500 > From: Paul Schlie <xxxxxx@comcast.net> > > So in summary, it would seem that all reader actions invoked by a reader > transform token should apply to the following correspondingly processed > <s-exp>, implying: (showing only reader actions) > > (' ' <s-exp>) :: ({quote {quote <s-exp>}}) => ((quote (quote <s-exp>))) > > (#; #; <s-exp>) :: ({remove {remove <s-exp>}}) => () > > (#; ' <s-exp>) :: ({remove {quote <s-exp>}}) => () > > (' #; <s-exp>) :: ({quote {remove <s-exp>}}) => (') ; error, unbound 'quote Would you agree that these should be equivalent?: (' #; a b) (' b) How about these?: (#; #; a b) (#; b) I think what you're missing in your comparison of ' and #; is this: ' consumes one sexp and produces one sexp. The resulting sexp can then be used as the argument of another '. In contrast, #; consumes one sexp and produces zero sexps. The resulting nothingness cannot be used as the argument to another #; because nothing is not a sexp. -al