From: E S <eero.saynatkari@...>
Date: 2005-02-01T14:51:23+09:00
Subject: Re: Partial function application (was: Re: Binding precedence for first sym...)

Trans wrote:

> E S wrote:
> 
>>Oh, I was serious. Partial function application (also referred to as
>>'macro binding' and 'currying') means that given a certain function
>>(or method), e.g.
> 
> 
> Ah, forgive me! I have heared of curry. I like to eat it :-) I have
> never noticed these other names for it before.
> 
> 
>>def fun(x, y, z)
>>  q = x + y + z
>>end
>>
>>If this function is invoked with a partial argument list, e.g.
>>
>>fun 1, 2
>>
>>Then, instead of throwing some sort of an error, the call would
>>produce a new function where the given arguments are bound.
>>Essentially, the previous call would yield:
>>
>>def fun(z)
>>  q = 1 + 2 + z
>>end
>>
>>So these calls would be equal:
>>
>>fun(1, 2, 3)          # => 6
>>((fun 1, 2) 3)        # => 6
>>fun(1, 2)(3)          # => 6
>>x = fun(1, 2); x(3)   # => 6
> 
> 
> I highly regard this. It should be so.
> 
> 
>>The only problem would be handling the destructive updates, i.e. what
> 
> 
>>would happen if one tried to curry this with x:
>>
>>def fun(x, y, z)
>>  x = x + y + z
>>end
>>
>>x can't be directly substituted since it's assigned to. It'd have to
>>be translated to 'xx = x + y + z' or something.
> 
> 
> I do not see a problem. The x is local and has no functional baring.
> The translation is simply:
> 
> fun(1,2)  #=>
> 
> def fun(1, 2, z)
> x = 1 + 2 + z
> end

Maybe 'problem' is too strong a word. Let's say it's not altogether 
straightforward: you can't just replace all instances of x in the
method body; can't replace in assignments and can't reuse after some
sort of an in-place modification (which should normally be denoted
with a !, but sometimes isn't). One could of course simply shelve the
responsibility to the coder but that's usually not the popular option.

>>This probably isn't something most Rubyists, at least initially,
> 
> would
> 
>>be excited about but it's quite useful. I think it'd be possible to
>>implement as a library but it'd obviously be fairly slow. Of course
>>there's always Haskell :)
> 
> I am for it. Much more so then for my silly symbol notation ;-)
>  
> T

E