Hello list,

The following issues in relation to the design of SRFI-26 have
been raised during the discussion since the last revision:

1) Is the mechanism useful at all?
2) Should the mechanism be more general?
3) What is the precise semantics of the mechanism?
4) How should the mechanism been named? (continued)

Ad 1)

Most important question. Contrary to my initial idea that the issue would
have to be settled by speculation and opinion alone, Mike Sperber
produced some empirical evidence by quickly scanning a program
of his. Prompted by this I have hacked a small program to scan other
people's programs for potential instances of the SRFI (details with
separate mail). I was surprised to see that the mechanism seems to
be more useful than I am experiencing it myself in the first place.

Ad 2)

It has been argued that the mechanism is too limited as it does not
allow permutation, omission and duplication of arguments. As an
example of a more general mechanism variants of lambda with
numbered arguments have been mentioned.

The deliberate design decision to restrict the mechanism to
projection, only, is based on some 10+ years of practical experience
with the 'numbered argument' mechanism: It is easily overused.

So far, still nobody has convinced me that we do ourselves a
favour in mixing the (restricted) 'projection' mechanism with the
(universal) 'numbered argument' mechanism in one single
macro that can then do specialization as well as general lambda.
The same holds for a combination with the other mechanisms
proposed so far, and with hypothetical 'more general solutions'.
It might not be obvious (just 18 lines of code!), but the design of
the mechanism I propose is more balanced than it appears.

Ad 3)

Al Petrovsky observed that the semantics of the mechanism has
not been defined properly with respect to the time when the argument
expressions and the procedure expression are evaluated.
This is particularly harmful if there are two possible implementations,
one with macros the other one with procedures.

After some thought, I have decided to go for the macro semantics
and to document the procedure semantics to prevent other people
from making the same mistake I made. After all, the macro implementation
is the one that is supposed to be most useful and the mechanism is
not important enough to justify the definition of a substantial ambiguity.

Ad 4)

To keep the matter short: I have decided to change the name of
the game into CUT. Cut as in "section", and c.u.t. as in "curry upon this",
"can use this", "curry under the hood (or not)?", etc. ;-)

I am still not so much impressed by the arguments and the polemic
for or against the names. However, the style of the discussion shows
me that the SRFI can benefit from a different name. During some
conceptual blockbusting on that I felt that shortening the name
might still be a good idea (as proposed several times) and from
CWIC it was led to CUT.

It is difficult for me to pull myself together not to become cynical
about the name discussion, but I will continue to listen to everything
that is said in the discussion forum. So please tell me what you think
about it. I have already given up hope for universal popularity, so
never mind speaking up :-)

-----

You will find the changes reflected in the forthcoming revision of
the SRFI that will soon be announced to the list.

Sebastian.