Hello list,

Initiated by the discussion on the SRFI-26 mailing list, I gave the design
of the mechanism some more thought.

The following issues have been raised up to now:
1. Is it important to allow procedural (non-macro) implementations?
2. Is it wise to use improper list notation for the rest-slot?
3. Should the syntax be changed by adding parentheses?
4. How should the "curry-which-isnt-curry" thing be named?

Ad 1.

Yes it is. Stephan's observation opens up a way to implement the
feature in every Scheme there is, even in the systems that do not yet
fully support R5RS macros as Felix mentioned. I have changed the
SRFI document and inserted a macro-free implementation, inspired
by and refering to Stephan's program.

Ad 2.

Due to the 1. issue and the fact that improper list notation might
not work as expected (as Felix pointed out), I chose to add a new
"rest-arg" symbol, which is exactly what Stephan proposed: <...>

Ad 3.

I think there is little to be gained by defining a more complicated
syntax. So unless I see a clear benefit of changing the syntax,
I prefer not to do it.

Ad 4.

Obviously, everybody who sent an email to suggest a new name
was aware of the fact that the macro I had called "curry" is not doing
currying (unwinding the parameters into a nesting). This was also
stated in the SRFI document, although, I admit probably not in the
most prominent place possible.

It is also obvious that there is a supporter for every name I can
think of what it should be called: curry, section, partial-apply,
specialise, partial-call, and partial.

Yet, the more I thought about it, the more I got the impression that
the argument "It's not currying, so don't call it currying!", although
certainly valid, does not end the story here. The most startling
observation for me: Ever since I invented the mechanism (back
in 1994) it was always crystal clear to me that a) the macro does
not do what is known as 'currying' and b) the macro should
be called "curry". In fact, I was completely surprised when
I found out that people have problems with that.

By now, I think the reason is simple: Currying is pointless in Scheme
but Curry-which-isnt-curry (as Stephan called it quite correctly) does
what Haskell achieves through currying. After all, it is not really
relevant what a function named "curry" does in Haskell when we
talk about Scheme. (Think about "list", "vector", "array", "lambda",
"->" "\" etc. Any resemblance anywhere?) Curry-which-isnt-curry
simply does the sequence: 1. curry 2. specialize 3. uncurry and that
is as close as it gets in the algorithmic language Scheme (apart
from didactics) as far as currying is concerned.

In this sense, we still owe H. B. Curry a reference to his name
(and lucky him, Schoenfinkel has seven letters more) for
telling us how to deal with multi-argument function elegantly.
Therefore, I would like to propose again (with bad conscience
this time) to call curry-which-isn-curry simply "curry" for brevity.
And, of course, the SRFI-document will be adjusted to make
absolutly sure _nobody_ misses the point that "curry" is what
"" (:= a left out parameter called x) is to Haskell.

Sebastian.