From: Gary Wright <gwtmp01@...>
Date: 2009-01-14T08:09:04+09:00
Subject: Re: functional programming

--Apple-Mail-198-177923416
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit


On Jan 13, 2009, at 1:37 AM, Mike Gold wrote:
>> Your specific suggestion that 'name()' could be syntactic sugar for
>> Proc#call introduces an ambiguity in the language that I find
>> disconcerting.
>
> There is no ambiguity because, as I mentioned, locals are determined  
> at
> parse time.  However notice I recanted the suggestion seven minutes
> later in the post which immediately followed, for similar reasons.

I should have quoted it, but I was responding to your very-late-in-the- 
conversation
comment:

> The topic was about the problems arising from the syntactic difference
> between methods and lambdas.  You've changed gears to a generic
> discussion about procs.  My question is yet unaddressed: 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.

Which I interpreted as support for the name() syntax for function  
application.

Presumably you would want function application to be available to any
expression though, not just to a local variable, and so I think you  
are still stuck with
the fact that parens can't be unambiguously interpreted during  
parsing.  You would
need some precedence rule.

a = object.generate_lambda
a()  # apply, because parser knows that a is a variable not a method  
call

object.generate_lambda()     # call, then apply  or just a zero  
argument call?
(object.generate_lambda)()  # call, then apply

I'm not arguing that it isn't possible to come up with some rules that  
would make it possible
for method/function application to be done via parens.  It just seems  
like an unnecessary
complication.

Gary Wright


--Apple-Mail-198-177923416--