Re: New block syntax

I fear that my mistake in posting to the wrong list has polluted
ruby-core. My name will be had for evil for years to come. But since
this is getting interesting (apologies to those that have expressed
otherwise) I think we might as well finish what we started:

Many thanks to David's last post. Comments like yours are just
what I'm looking for to catch what I've missed. Let me take them to
the next level:

> I tend to agree with Dan Berger on all of this; it seems like a
> solution in search of a problem.

We are looking at this from different angles. My proposal is
conditional, in the sense that _if_ proc syntax were to lose the
'proc' label ({}), _then_ I would prefer that hash syntax change to
avoid the {||} ugliness. You may (probably) still disagree, but let it
be known that I was trying to 'fix' the {||} problem. This all goes
away if the 'proc' comes back, of course. On a side note, matz gave a
sample RCR in his slides that proposed elimiating 'proc' entirely in
favor of Proc.new. Was that just an example or does he really support
that? I would prefer {} over Proc.new{}.

Back to the 'what if procs didn't have the proc label anymore' scenario...

> Actually it sounds like less flexibility and more fragility.

Could be. There already exists some fragility in hash/block syntax
that we've all grown to know and love (do_it {} {} for example). This
might trade previous fragility for new, which I don't like either. But
read on, I think your fear of increased fragility may be allayed.

> For example, I suspect the answer to my questions above would be:  commas
> would not be allowed as hash key/value separators any more

Ah, yes. You're correct. I have never used that syntax (nor seen it in
anyone else's code) in my meager 3 years of ruby life, so I admit, I
was unaware. This might not be such an issue if ruby2's new hash
syntax didn't allow for the comma separated key,value pairs anymore.
It appears to me to be an old syntax that might be phased out, who
knows. I'm curious what the devs have to say about that. If they kept
it, we would have 3 hash literal constructs  ('=>', ':' and ','). The
':' is new and here to stay, the '=>' is the most common, so maybe we
can live without the ','.

> whitespace would be required before a symbol argument to a method,

This behavior is already part of 1.9. Rev it up and see for yourself:

def sym2str(s); s.to_s end

p sym2str:'sym'  # {:sym2str=>"sym"}
p sym2str :'sym' # "sym"

My proposal doesn't introduce this new 'fragility'.

> and so on.

I'd love to hear the 'so on'. We haven't really hit a solid brick wall
yet, so far just the comma-separated key,value syntax, which, if still
around in 1.9, could still be available via Hash[]. Help me see the
light.

In the mean time, I have to say that the new syntax is growing on me.

array = [1,2,3]
hash  = [key:value]
proc  = { puts "you called?" }

The simplicity is attractive, plus we have virtually eliminated the
blurry line between procs and blocks. Yea, yea, I know, you just don't
like it. Could this have to do with you having more lines of code to
convert than I do? :)

Dan