[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I received these comments about SRFI-0 from someone who wishes to
remain anonymous. I'm posting them to srfi-0@xxxxxxxxxxxxxxxxx for
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)
but instead I have to write:
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
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.
(cond-implements (foo a b)
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
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.
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'.