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:http://per.bothner.com/tmp/srfi-108/srfi-108.htmls/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.
Both documents: 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. 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 per@xxxxxxxxxxx http://per.bothner.com/