 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> One Haskell VFAQ is "What is a monad?"
http://byorgey.files.wordpress.com/2011/05/monad_tutorial.jpg
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The question is, does
>
>> multiplierFunction(3)(4)
>
>> or similar yield a 12?
>
> Yes.
Right. So if you implemented all your stuff to take one argument at a
time like this [which would presumably be a little bit of work], IMHO
you could perfectly well call that "curried functions".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2012 06:03 PM, Warp wrote:
> That's kind of what the C++ lambda does internally: It puts the captured
> variables in some kind of internal struct, which the function then operates
> with (similarly to how a class member function operates with the object
> using the 'this' pointer). You could achieve a similar behavior by writing
> a class, but a lambda achieves this with significantly less effort.
Oh, so it can capture local variables too? That's even better than I
thought...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2012 05:34 PM, clipka wrote:
> Maybe that's what scrambles my mind whenever I read "Haskellists'"
> explanations of stuff: They're so proud that Haskell does it
> automatically for you, that they tend to deny the obvious parallels.
>
> So yes: Currying *is* like writing a function that takes fewer
> arguments, calling the original one and supplying (unchangeable)
> defaults for the missing arguments.
>
> And yes, apparently Haskell provides syntactic sugar for that. Wow. Big
> deal.
>
>> Finally, like I said, currying works backwards too: If a function call
>> happens to return a function as its result, you can just keep appending
>> arguments. "head function_list 7" and all that.
>
> Again, nice-to-have syntactic sugar, but nothing conceptually
> fascinating (as you noted yourself).
You seem to be missing the third point: Function currying allows you to
write code that polymorphically accepts functions with ANY number of
arguments.
That can be a Big Deal.
That said, yeah, of all the things that Haskell does, function currying
is one of the less exciting ones.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> One Haskell VFAQ is "What is a monad?"
>
> http://byorgey.files.wordpress.com/2011/05/monad_tutorial.jpg
Post a reply to this message
Attachments:
Download '960526421_mnnqb-o-1.jpg' (24 KB)
Preview of image '960526421_mnnqb-o-1.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2012 6:44 PM, James Holsenback wrote:
> hmmmm ... nonads (well that's self explanatory) better yet faux-nads ...
> someone who thinks that gotta pair. OK I'll stop now ;-)
I think, for everyone's sake, that you had better. ;-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2012 08:44 PM, Stephen wrote:
> On 22/04/2012 6:44 PM, James Holsenback wrote:
>> hmmmm ... nonads (well that's self explanatory) better yet faux-nads ...
>> someone who thinks that gotta pair. OK I'll stop now ;-)
>
> I think, for everyone's sake, that you had better. ;-)
Christ knows what happens if I ever try to explain group
homomorphisms... o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2012 8:52 PM, Orchid Win7 v1 wrote:
> On 22/04/2012 08:44 PM, Stephen wrote:
>> On 22/04/2012 6:44 PM, James Holsenback wrote:
>>> hmmmm ... nonads (well that's self explanatory) better yet faux-nads ...
>>> someone who thinks that gotta pair. OK I'll stop now ;-)
>>
>> I think, for everyone's sake, that you had better. ;-)
>
> Christ knows what happens if I ever try to explain group
> homomorphisms... o_O
LOL
And I think, for everyone's sake, that you had better not. ;-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2012 13:24, Warp wrote:
> I try to suggest "is like this?" the answer is "not really".
That's part of the problem. Occasionally there will be relatively simple
concepts that aren't "like" anything else. You just have to learn the concept.
It's like I read someone wrote about quantum computers. Someone asked "can
you give an example of how that quantum computer algorithm would be written
for a normal computer?" And the person said "No. That's the point. If you
could write it for a normal computer, you wouldn't need a quantum computer."
In the case of currying, the simple concept is that a function F that takes
arguments X, Y, and Z, is the same as a function G that takes argument X and
returns a function that takes Y and Z, such that for all X, F(X,Y,Z)
returning G_x(Y,Z) implies G_x(Y,Z) returns the same as F(X,Y,Z). It's a
simple mathematical statement, not "like" anything in an imperative language
that doesn't do currying.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/22/2012 9:51, Warp wrote:
> but the values to which they are fixed is determined at runtime rather
> than at compile time.)
You'd wind up having something closer to "objects" with an "invoke" method
(or functors, if I recall the C++ term). It's just that Haskell makes that
automatic, in the same way the new C++ makes class definitions automatic
when you type a lambda expression. Given enough convenience, you get a
qualitative difference.
> There are probably even deeper implications.
In all honesty, currying was created for computer science, not for computer
programming. It was invented so you could prove things about a one-argument
function that returns one value and apply those proofs to functions that
take multiple arguments and return multiple values. I.e., it was invented
for the same reason it was useful to invent UTMs, or to prove that any
2-tape TM can be emulated by a one-tape TM.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
