From: Michael Lucas-Smith <s3225202@...>
Date: 2002-01-19T08:19:17+09:00
Subject: Re: Proc.class vs yield

David Alan Black wrote:

> 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.
> 


I see what you're saying. I suggest that perhaps it was a mistake to 
re-use the same syntax between hash and block. Obviously that cannot be 
fixed now, but perhaps [] can be used to represent a proc so that:

proc { ... }
and:
[ ... ]

mean the same thing.

Michael