SRFI-108 and SRFI-109 final candidates available Per Bothner (17 Apr 2013 18:06 UTC)
Re: SRFI-108 and SRFI-109 final candidates available John Cowan (17 Apr 2013 20:32 UTC)
Re: SRFI-108 and SRFI-109 final candidates available Per Bothner (17 Apr 2013 23:56 UTC)
Re: SRFI-108 and SRFI-109 final candidates available John Cowan (18 Apr 2013 02:29 UTC)

Re: SRFI-108 and SRFI-109 final candidates available John Cowan 17 Apr 2013 20:32 UTC

Per Bothner scripsit:

> http://per.bothner.com/tmp/srfi-108/srfi-108.html

s/using same/using the same/
s/specifiction/specification/ (twice)

> http://per.bothner.com/tmp/srfi-109/srfi-109.html

s/identation/indentation/

Period did not get added to tag-subsequent.

Rather than referring to R7RS productions, duplicate them in order to help
maintain SRFI 109 as a self-contained document.

Both documents:

Is there a need for [ and ] in SRFI 109 in order to escape
unbalanced brackets in SRFI-108 constructors?

Defining the variables $<<$ and $>>$ as empty strings sounds clever,
but unfortunately none of R[4-7]RS require either `eq?` or `eqv?` to be
able to distinguish between two instances of the empty string.  Scheme
implementations are allowed to coalesce them all into a single instance.
So if they are to be defined as strings, they need to be non-empty if
`$string$` and `$construct:*` are to be definable as functions rather
than as macros.  I suggest:

    ;; Calling string-copy guarantees that these are unique objects.
    (define $<<$ (string-copy "$<<$"))
    (define $>>$ (string-copy "$>>$"))

This means that the sample definition of $string$ has to work a little
harder, skipping arguments that are `eqv?` to either of these variables.
Literal appearances of "$<<$" or "$>>$" in text, or appearances as the
result of evaluating expressions, are guaranteed never to be `eqv?`.

--
Some people open all the Windows;       John Cowan
wise wives welcome the spring           xxxxxx@ccil.org
by moving the Unix.                     http://www.ccil.org/~cowan
  --ad for Unix Book Units (U.K.)
        (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)