|No such thing as a small change|
Re^13: Near-free function currying in Perlby BrowserUk (Pope)
|on Nov 20, 2004 at 08:58 UTC||Need Help??|
Sorry for the delay on getting back to you Tom; I was off reading. Though you may regret my ever getting back to you once you've read this :) (I hope that's a joke!)
When I wrote:
Nope. No matter how hard I try, I cannot see any merit in currying, and especially not Autocurrying in Perl (5).
I omitted a comma (indicated above), which (I think) changes the meaning of the sentence such that you quoted the sentence and responded to it in two halves.
I do see the merit in currying--in Haskell and other FP langauges. It is a fundamental part of those languages, and of their underlying philosophy and implementations.
Indeed, it would be (pretty much?) impossible to write a Haskell program that didn,t use currying--transparently and ubiquitously.
But that's my point. It's use in Haskell (and others) is so fundamental, that is "just happens". The Haskell programmer has no need to think about which functions he should curry, when he should curry them, or how to do the currying. He just composes those functions he requires, in the appropriate order, from the other functions who's outputs, are the inputs the new function needs, using the usual syntaxes, and if a function needs currying, it is done.
At no point in the process does he have to think:
"When I come to use this function, I won't (may not) have all the arguments available to me, so therefore I better curry it now with this or that partial set of arguments, so that the curried version is available when I need it later."
To be able to use currying (or autocurrying) in Perl(5), that s exactly the type of foresight and decision that the programmer would need to make.
From here on down, I'm walking on dodgy ground. I'm going to speak like I understand (some) of Haskell, which is a flawed assumption at this stage, but it's the only way I can express what I'm trying say. Please make allowances
Haskell's transparent currying has some nice side-effects. When constructing your program, you can start top-down and if at some point in the definition of the program you discover that you need a value that will be obtained or derived from a function that you haven't coded yet. No problem.
Invent a name for that function and use it. Provided you have at least one of it's parameters available now on which to later trigger the currying of the rest, then Haskell will ignore that the full function is not yet defined, and allow you to fill in the blanks in a later definition. The compile-time pattern matching process will take care of making the appropriate connections between this partial function use and a corresponding later definition that matches it.
That is a very powerful concept. In some ways it is remenicient of the Prolog style of doing things. Except, if I remember my long distant flirtation wth Prolog, it would quite happily go ahead and start running your code (often for hours as I recall :), before belatedly discovering that it didn't actually have a rule to cover a situation that could arise. That absence of "compile time completeness checking" is one reason (IMO) that Prolog never made it as a mainstream language. If I have understood any of this, I think that Haskell would detect whether you have used a partial function pattern for which you had not provided an appropriate definition, pretty early. Ie. When it attempts to make the appropriate bindings at "compile time"?
And that, I think, is the problem I see with using currying in P5. It doesn't allow you to use a function for which it has no prior knowledge. (Method calls aside.)
Perl also doesn't have any mechanism for performing pattern matching (in the namespace sense of that term--otherwise known in OO (principally C++) circles as name-mangling). This means that it is pretty impossible to automate the process of currying, other than through presumptive positional criteria. That's further exacerbated by Perl's allowing variable numbers of arguments to functions (as you mentioned), combined with the "typeless" nature of Perl's arguments. Every parameter is a scalar--and a scalar can be (quite literally) anything.
Indeed, it is Perl's total absence of a formal argument binding mechanism, typeless (more generously termed polymorphic) scalar parameters, that force you to encode the types of the curried parameters into the function names. You are, in effect, having to do the pattern matching or name mangling yourself.
Automating this process (in P5) would be really quite hard to get right, as you would have to effectively replicate the P6 signatures and muiltimethods concepts. And the only real option for doing that would be to do runtime discovery of parameters through the likes of can, ref and isa. A rather messy, and expensive, runtime cost.
In fact, TheDamian has already released a module for performing Perl6::Currying, along with a supporting module, Perl6::Placeholders. As a source filter it may not be to everyones taste, but that does allow some or all of the work in performing the pattern matching to be confined to compile-time rather than run-time.
Even there, the examples are of the halve(); double(); treble(); type, which allows me to say:
The value of which eludes me? As, taken to it's ultimate conclusion, I'd also need definitions for:
So, whilst I criticised your original Perlish example, I also praised your attempt to find one that was non-trivial.
Thanks for taking the time to put your doubts in writing. That takes guts, especially when you're sitting in the FP-cheerleading part of the stadium.
Trying not to sound too much like a Hollywood awards ceremony;
Thanking you, for recognising that my writings are indeed expressions of my doubts, and my attempts to resolve them. Not any pronouncement of "the way it is" or definitive conclusion. When I reach a conclusion on a subject, I rarely join in discussion of it; unless I see something that causes me to question my conclusions.
On this subject, I have not yet reached any conclusions. I have my leanings, which are probably fairly evident by now, but there are also enough indicators that I am leaning the wrong way for me to know that I still need to keep an open mind and do a lot more reading and experimentation on the subject.
Examine what is said, not who speaks."But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon