From: pjb@... (Pascal J. Bourguignon)
Date: 2009-01-14T23:09:11+09:00
Subject: Re: functional programming

"David A. Black" <dblack@rubypal.com> writes:

> Hi --
>
> On Wed, 14 Jan 2009, Pascal J. Bourguignon wrote:
>
>> Mike Gold <mike.gold.4433@gmail.com> writes:
>>
>>> Pascal J. Bourguignon wrote:
>>>> Mike Gold <mike.gold.4433@gmail.com> writes:
>>>>
>>>>> Why is func.call() or func[] or func.() "very useful" compared to
>>>>> func()?  As I mentioned, in every case I've found it to be a
>>>>> hassle, for the reasons previously stated.
>>>>
>>>> The reason is because Ruby is a lisp-2.  The same name can be used to
>>>> designate both a method and a variable.  So you need two syntaxes, to
>>>> make reference to the method of a name, or to the variable.
>>>
>>> No, that's not the reason.  It is because Ruby allows method invocation
>>> without parens.  Therefore parens cannot be used to unambiguously
>>> "dereference" a function.
>>
>> It wouldn't matter if we had not to distinguish calling a named
>> function from calling a function stored in a variable.
>
> But what would this be:
>
>    f = lambda {}
>    def f; end
>    f()

It's clear, f() calls the def f.
You need and have another expression to call the lambda.

And this is because there are two things that are designated by the identifier f here:

- A function defined with def.
- A variable assigned with =.

Or, said more concisely, Ruby is a lisp-2.


> I don't think you can express all of Ruby's object model and
> assignment semantics if you remove the message-sending semantics from
> Proc objects. That's the problem: not when it's one or the other, but
> when it's both. (I'm not a big fan of the magical dereferencing of
> Procs, I admit, but I'm not sure how it would work even if it were
> done.)

-- 
__Pascal Bourguignon__