[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-108 and SRFI-109 final candidates available

This page is part of the web mail archives of SRFI 109 from before July 7th, 2015. The new archives for SRFI 109 contain all messages, not just those from before July 7th, 2015.

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:


s/using same/using the same/

Thanks - fixed.

s/specifiction/specification/ (twice)

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



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

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