[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.
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.
Is there a need for [ and ] in SRFI 109 in order to escape
unbalanced brackets in SRFI-108 constructors?
[ and ] 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.