Oops - I'm sorry.  I uploaded the files to the wrong directory.
They should be ok now.  My apologies for wasting your time.

On 04/17/2013 01:32 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>> http://per.bothner.com/tmp/srfi-108/srfi-108.html
>
> s/using same/using the same/

Thanks - fixed.

> s/specifiction/specification/ (twice)

Fixed (already in local and new-uploaed version).

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

Likewise was already fixed.

> Period did not get added to tag-subsequent.

Sorry - that was fixed in my local copy/

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

As a matter of style, I think this questionable - duplicating
definitions from existing standards is a mistake.  (Where would
you stop?  Duplicate the entire definition of <expression>?)
However, in this case R7RS is not yet ratified.  It might be better
to refer to R6RS.

> Both documents:
>
> Is there a need for &lbrack; and &rbrack; in SRFI 109 in order to escape
> unbalanced brackets in SRFI-108 constructors?

&lbrack; and &rbrack; are not required in my copy.

> 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.

(Note you may have read an earlier draft where $<<$ and $>>$
were initialized to "".  They are now initialized to (make-string 0).)

Not by my reading: make-string returns a "newly
allocated string", so while eq? is allowed to #t for the result
of the different calls to make-string, it violates most people's
expectations of how eq? works.  Is there any Scheme implementation
where (eq? (make-string 0) (make-string 0)) return #t?

I tweaked the draft to discuss this (theoretical) possibility:

   Note that R6RS and R7RS allows eq? to return #t for distinct
   calls to (make-string 0). A hypothetical implementation that
   does so needs to initialize $<<$ and $>>$ some other way.

SRFI-109 can't be implemented by a portable library anyway,
so it seems fine to make such a requirement.   Given that
it would be a really weird Scheme implementation where it
is an issue.

> 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?`.

I don't care about making $string$ more complex, but I do care about
making $construct$:foo harder to write.  True, in many case we can
hide the complexity in define-simple-constructor (that might have
been missing in the version you reviewed).  In many other cases
$construct$:foo will be a macro where it doesn't matter what
$<<$ and $>>$ evaluate to.  In other cases, we can ignore them,
and it's ok if they evaluate to "" without it mattering if they're
unique.

However, I don't think this is an actual problem, and initializing
there to (make-string 0) seems fine.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/