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

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

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/