This page is part of the web mail archives of SRFI 26 from before July 7th, 2015. The new archives for SRFI 26 contain all messages, not just those from before July 7th, 2015.
On Mon, Feb 25, 2002 at 10:00:37AM +0100, Michael Sperber [Mr. Preprocessor] wrote:
> >>>>> "Stephan" == Stephan H M J Houben <Stephan> writes:
>
> Stephan> OK, so this isn't a serious proposal, but at least it is better
> Stephan> than using curry . I really don't understand how people can seriously
> Stephan> suggest to choose curry and go for a head-on clash with the whole FP
> Stephan> lterature.
>
> Let me again suggest that you guys read Sebastian's elaborate posting
> on the issue at
>
> http://srfi.schemers.org/srfi-26/mail-archive/msg00016.html
Thank you verymuch. I did read it, but didn't respond to it,
because I don't like to beat a dead horse. I then believed I made
my point and could leave it to others (or even Sebastian himself,
after a bit of sleep) to point out the obvious flaws. After all,
it is Sebastian's SRFI, and as far as I understand the whole process,
he has the final say.
But since you accuse me of "not replying to that post", I will
do so now (well, only to part 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.
So far, so good. Curry isn't what it does, and there is plenty support
for other names (although there is still some discussion).
>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.
"It was always clear to me that the macro should by called currying."
No argument is given here. We're now leaving the path of logical
reasoning and asked to blindly follow the crystal clear design decisions
of Sebastian. He admits himself that the macro does not do what it says it
does, yet he is "completely surprised" that people object to that. ????
>By now, I think the reason is simple:
>Currying is pointless in Scheme
Nonsense! Currying is meaningful and useful in Scheme.
Possibly less so than in Haskell, but nevertheless useful.
>but Curry-which-isnt-curry (as Stephan called it quite correctly) does
>what Haskell achieves through currying.
No. What Haskell achieves through currying is simulating multiple-argument
functions. If you think that doing a section such as "(+) 3" is doing
currying in Haskell, you are mistaken. This is an application. The fact
that it works as a partial application has indeed to do with the
fact that (+) is a curried function, but the operation called
"currying" took place when (+) was defined in the first place.
At best, Sebastian is writing unclearly here. At worst, he is
confused about the meaning of the word "currying" as used by
the Haskell and FP community.
>After all, it is not really
>relevant what a function named "curry" does in Haskell when we
>talk about Scheme.
But the whole point of the macro was to simulate something
that can be done in Haskell? Besides, "curry" is widely used
in the whole FP community, of which Scheme is also a part,
according to some. Now if curry came from COBOL, I wouldn't
worry that much, but to clash with Haskell is Very Bad, IMNAAHO.
>(Think about "list", "vector", "array", "lambda",
>"->" "\" etc. Any resemblance anywhere?)
I think about them. There are no resemblances, but also no
nasty clashes.
>Curry-which-isnt-curry
>simply does the sequence: 1. curry 2. specialize 3. uncurry
If that were true, we could only specialise on the first argument.
>and that
>is as close as it gets in the algorithmic language Scheme (apart
>from didactics) as far as currying is concerned.
No. Real currying in Scheme is:
(define (curry proc)
(lambda (x)
(lambda (y)
(proc x y))))
and this can be useful, also in "non-didactic" situations.
Nice rhetorics, BTW, to use "didactic" here suggesting that
any counter-example is not "Real World"(TM) or something
like that.
>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.
It's only elegant if you bought in to the Haskell PR department.
Frankly, I think Haskell's handling of multi-arg functions
is awful for n+1 reasons but let's save that discussion for another flame.
So we don't owe H.B. Curry a reference to any macro that claims
to handle multi-arg functions "elegantly". Rather, we owe it
to ourselves to use words according to their accepted usage.
>Therefore, I would like to propose again (with bad conscience
>this time)
So why propose it then? Again, the only advantage that is given
is that it is "crystal clear" that it is the right thing,
nd that we somehow owe H.B. Curry a reference to something
he didn't invent.
>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.
...and of course, all maintenance programmers who encounter curry
in the code and all students who encounter it in their homework
will immediately go to this SRFI and not even think about
entering "curry" into google and looking at the first programming-related
hit, being
http://www.informatik.uni-kiel.de/~mh/curry/
"The functional logic language Curry", which, to be sure,
uses "curry" in the traditional FP sense.
Greetings,
Stephan