Email list hosting service & mailing list manager

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)

Formal spec; implementation; nesting Alpert Herb Petrofsky 10 Jan 2005 23:21 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