From: "David A. Black" <dblack@...>
Date: 2009-08-24T19:01:05+09:00
Subject: [ruby-core:25085] Re: Proposal: Simpler block format

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1926193751-1487219535-1251108050=:24915
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Hi --

On Mon, 24 Aug 2009, Yehuda Katz wrote:

> Essentially, we currently have two semantic constructs: method-style and
> block-style. I am suggesting that we take the literals of each style and use
> them as literals whenever those semantics are expected.
> �� �my_method { block_semantics }
> 
> In this case, { block } is the literal for block-semantics. I am suggesting
> that we extend the use of this literal to the other case where
> block-semantics are used: Procs.
> 
> �� �my_method({ still_block_semantics })
> 
> Similarly:
> 
> �� �def method_name() method_semantics end
> 
> In this case, def is the literal for method-semantics. I am suggesting that
> we extend the use of this literal to the other case where method-semantics
> are used: Lambdas.
> 
> �� �name = def { still_method_semantics }
> 
> As you can see, by using the same literals for equivalent constructs, we
> simplify the problem in the mind of the programmer. When he sees "def" he
> knows that method semantics are to be used, and required arguments are
> required, return will return from the block, and yield will yield to the
> block. When he sees bare {} he knows that block semantics are used, all
> arguments are optional, return will return from enclosing "def", and yield
> will yield to block passed into enclosing "def".
> 
> This will always be true, no matter if lambda is being used, proc is being
> used, method is being used, or block is being used.

I think I can put a bit of flesh on the bones of my dislike of the
bare {} to mean a proc.

It has to do, at least in part, with left-to-right visual parsing.
When I see this:

   x = {

I want to know what the { means, without having to read further to the
right, looking for a hashrocket, and then backtracking.

I know that it doesn't actually consume much time, but it still feels
awkward to me -- like there are too few tokens being used to represent
the number of possible outcomes, so an extra parsing (human) step is
required.

It's different from, say, this:

   def a(*); end
   a = [1,2,3]
   a [0]

where you could say that you don't know whether the [ is an array
literal or the [] method -- except that you do know, because there's a
rule that is applied, and that allows for strict left-to-right
parsing.

So I would rather continue to have hashes and procs differentiated by
more than what's inside the {}'s.


David

-- 
David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com
Q: What's the best way to get a really solid knowledge of Ruby?
A: Come to our Ruby training in Edison, New Jersey, September 14-17!
    Instructors: David A. Black and Erik Kastner
    More info and registration: http://rubyurl.com/vmzN
--1926193751-1487219535-1251108050=:24915--