This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
I received these comments about SRFI-0 from someone who wishes to remain anonymous. I'm posting them to srfi-0@xxxxxxxxxxxxxxxxx for the record. Marc Anonymous wrote: 1. It is amost certainly a mistake to base feature-ids on SRFI document numbers. There are many reasons why this is a bad idea, but it should be sufficient to point out that when I'm -reading- a piece of Scheme code, how am I going to figure out what `(if-implements SRFI-17 ...)' does? I have to look it up somewhere. So why not write `(if-implements extensible-strings ...)' instead, and save me the trouble? SRFI-0 hints that there might be "aliases" for feature-ids, presumably nice mnemonic names, which I guess is supposed to address this problem. Presumably people will be encouraged to use the mnemonic aliases to keep their code readable. So then what's the point of the document number based IDs? You should just be giving features mnemonic names from the very beginning. 2. Logical combinations of features will be wanted all the time. Suppose there is an easy way to do something only if -both- the `foo' and `bar' features are available. I would like to write: (if-implements (and foo bar) easy-way hard-way) but instead I have to write: (if-implements foo (if-implements bar easy-way hard-way) hard-way) duplicating the hard-way code. Yes, I can write my own feature testing macro that implements "feature expressions" and expands into the appropriate nest of `if-implements' expressions, but this is such a common thing to want that it might as well be built in to the basic mechanism. 3. I'd like to have something with a `cond'-like syntax, instead of an `if'-like syntax. I can always define this myself, but I'm mentioning it here anyway because it might provide a clearer way to decide when the lack of -any- matching feature is an error: you can use the lack of an `else' clause to indicate that one of the alternatives -must- be true. For example: (cond-implements (foo a b) (bar c)) is equivalent to `(begin a b)' if `foo' is an available feature, it is equivalent to `c' if `foo' isn't available, but `bar' is, and it is an error if neither `foo' nor `bar' is available. Then I can include an empty `else' clause if it is OK for neither `foo' nor `bar' to be available. The value of such `cond-implements' expression can be the usual unspecified value. My reply was: I am (now) also leaning towards a multiway conditional and the use of "and", "or", "not". I like your idea that a non-existent "else" clause indicates that an error must be signaled if none of the SRFI's are available. About the "SRFI-n" feature-ids which you find less readable than explicit feature names, I agree that it would be more readable but there is a problem with naming different versions of a feature (i.e. a SRFI author who extends his/her SRFI to add some functionality thus creating a new SRFI), or different proposals for similar features (i.e. different authors writing SRFIs to provide a given feature). Let's say you wrote a SRFI named "extensible-strings" and I have what I think is a better way of doing extensible strings, how will we call my SRFI? extensible-strings2? I prefer to use a boring SRFI-n name until a particular extensible string SRFI has become well accepted, and then the editors can attribute an alias like "extensible-strings" to the accepted SRFI. At this point we are back to the same problem as before, but the problem is less severe because there is less of a chance that counter proposals will surface. Anonymous replied: Naming your proposal `extensible-strings2' is better than naming it `SRFI-259'. I have some chance of remembering what `extensible-strings2' means. I expect that there will usually be some way to capture the difference between two proposals that is better than naming the one `foo' and the other `foo2', but even if that is the best that you can do, it still beats `SRFI-23' and `SRFI-259'.