From: David Alan Black <dblack@...>
Date: 2002-01-18T23:03:44+09:00
Subject: Re: Proc.class vs yield

Hello --

On Fri, 18 Jan 2002, Michael Lucas-Smith wrote:

> Not really, I want to be able to write the following:
>
> def method (a,b,c)
> 	a.call
> 	b.call
> 	c.call
> 	yield
> end
>
> method { doA }, { doB }, { doC } { doD }
>
> instead of writing:
>
> method proc { doA }, proc { doB }, proc { doC } { doD }
>
> having to write all those 'proc's is nasty. Just purely nasty. I see no
> reason why the compiler couldn't be smart enough to assume the 'proc'
> for you. It should easily be able to tell the difference between an
> array and a block -- since it already does for the yieldable anonymous block
  ^^^^^

(I think you mean hash, not array.)  The thing is, syntactically, the
anonymous block associated with a method call occupies a unique
position, so it's clear what it's for.  But with this:

> method { doA }, { doB }, { doC } { doD }

I don't see how the parser could tell whether A/B/C were procs or
hashes.  Actually I've had some trouble coming up with a {...}  string
that parses as both a hash and a proc... but I *really* don't think
there should be a rule that if something has the wrong number of
elements for a hash, it should be assumed to be a proc.  (I've been
saved by the "odd number" error too many times to wish for that :-)

Wait, I take it back.  Here's one that parses both ways:  {}

  method({}, {}, {}) { puts "weird, but it makes the point"}

Other than extremely cumbersome internal lookups and guesses about
what programmers are likely to have meant, I can't see how this could
be disambiguated.

(Just wondering: is there similar debate about the lambda keyword [or
function, or whatever it is] in Lisp?)


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav