[ruby-core:25082] Re: Proposal: Simpler block format

This could also be a problem:

   m { "block" }
   m 1, { "proc" }
   m(1) { "block" }

I like the idea, but in fact, I've always wanted to get rid if the  
blocks, only use procs and have this syntactic sugar:

   m { 123 } # m({ 123 })
   m(1, 2, 3) { 456 } # m(1, 2, 3, { 456 })

This would also blur the lines between procs and other "runnable"  
objects. So as long as you simply call #call on the proc-ish  
parameter, you don't actually have to pass in a proc. We could for  
instance define Symbol#call and you would be able to do:

   thing.each(:to_s)

And it would be fast. Maybe #call is too common, but you get the idea.

There problems with this is that it would break older code.  
block_given? and yield doesn't make any sense since there is no "the  
block" only "a proc passed somewhere as a parameter"

But hey, I'm only dreaming. 3.0 maybe?

//Magnus

On 24. aug. 2009, at 00.33, Yukihiro Matsumoto <[e-mail]>  
wrote:

> Hi,
>
> In message "Re: [ruby-core:25049] Re: Proposal: Simpler block format"
>    on Sun, 23 Aug 2009 15:53:03 +0900, Yehuda Katz  
> <[e-mail]> writes:
>
> |Things that currently don't parse are fine to become blocks. I'd be  
> worried
> |about a case that currently parsed fine as a Hash but might be  
> expected to
> |be parsed as a block if this feature existed. Can you think of any?
>
> I don't worry about the ambiguity for the parser, but have anxiety for
> humans.  Under the new syntax, when we see
>
>  m {"this is a block not a proc"}
>
> there are two possibility.  And it would be burden for mind of the
> programmers.  That's the reason I insisted the past proposal (that
> was from David Black, IIRC).  This time, we have working code for the
> proposal, so we can try.  Let's see how we feel.
>
>                            matz.
>
>