From: Yehuda Katz <wycats@...>
Date: 2009-08-24T06:27:43+09:00
Subject: [ruby-core:25054] Re: Proposal: Simpler block format

--00c09f8e5c386e01600471d5c5a1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sun, Aug 23, 2009 at 2:00 PM, Caleb Clausen <caleb@inforadical.net>wrote:

> Yehuda Katz wrote:
>
>> On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb@inforadical.net
>>  How do you disambiguate this case:
>>
>>     { foo bar => baz }
>>
>>    which could be parsed 2 ways:
>>     { foo(bar) => baz } #a hash
>>    or
>>     { foo(bar=>baz) }   #a block
>>
>>
>> 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?
>>
>
> There's these 2, which parse as hashes currently:
>
>  { p () => () }
>  { p {} => {} }
>
> Which confuse me, and presumably other humans. Maybe not confusing to
> parsers...


Both of those cases continue to parse as a Hash with this patch.
Effectively, the patch simply fills in SyntaxError cases of { ... }, which
should mean that anything that parsed as a Hash before will continue to do
so, but anything that couldn't parse before will become a proc.


> If you want to just define my first example to be a proc, that's fine. (I
> think it will be easy enough to implement that way....)
>
> But I'd like to see a more explicit description of how this would work, if
> I am to implement it. Making reference to an existing parser implementation
> is unhelpful for me, especially as I am not familiar with the internals of
> that implementation. Things that cause parse errors for MRI may not for
> redparse; redparse is generally looser and more tolerant than MRI parse.y.
> In other words, what would the appropriate section of a ruby standard read
> when describing this feature?


Understood -- but you do have the implementation to refer to. I agree that
in order for this to be accepted, we would need to provide new RubySpecs to
specify the behavior. I believe ujihisa is working on that.

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--00c09f8e5c386e01600471d5c5a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Aug 23, 2009 at 2:00 PM, Caleb C=
lausen <span dir=3D"ltr">&lt;<a href=3D"mailto:caleb@inforadical.net">caleb=
@inforadical.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Yehuda Katz wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen &lt;<a href=3D"mailto:caleb@=
inforadical.net" target=3D"_blank">caleb@inforadical.net</a>  =A0 =A0How do=
 you disambiguate this case:<div class=3D"im"><br>
<br>
 =A0 =A0 { foo bar =3D&gt; baz }<br>
<br>
 =A0 =A0which could be parsed 2 ways:<br>
 =A0 =A0 { foo(bar) =3D&gt; baz } #a hash<br>
 =A0 =A0or<br>
 =A0 =A0 { foo(bar=3D&gt;baz) } =A0 #a block<br>
<br>
<br>
Things that currently don&#39;t parse are fine to become blocks. I&#39;d be=
 worried about a case that currently parsed fine as a Hash but might be exp=
ected to be parsed as a block if this feature existed. Can you think of any=
?<br>


</div></blockquote>
<br>
There&#39;s these 2, which parse as hashes currently:<br>
<br>
 =A0{ p () =3D&gt; () }<br>
 =A0{ p {} =3D&gt; {} }<br>
<br>
Which confuse me, and presumably other humans. Maybe not confusing to parse=
rs...</blockquote><div><br></div><div>Both of those cases continue to parse=
 as a Hash with this patch. Effectively, the patch simply fills in SyntaxEr=
ror cases of { ... }, which should mean that anything that parsed as a Hash=
 before will continue to do so, but anything that couldn&#39;t parse before=
 will become a proc.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">If you want to just define my=
 first example to be a proc, that&#39;s fine. (I think it will be easy enou=
gh to implement that way....)<br>


<br>
But I&#39;d like to see a more explicit description of how this would work,=
 if I am to implement it. Making reference to an existing parser implementa=
tion is unhelpful for me, especially as I am not familiar with the internal=
s of that implementation. Things that cause parse errors for MRI may not fo=
r redparse; redparse is generally looser and more tolerant than MRI parse.y=
. In other words, what would the appropriate section of a ruby standard rea=
d when describing this feature?</blockquote>

<div><br></div><div>Understood -- but you do have the implementation to ref=
er to. I agree that in order for this to be accepted, we would need to prov=
ide new RubySpecs to specify the behavior. I believe ujihisa is working on =
that.</div>

</div><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.132=
5<br>

--00c09f8e5c386e01600471d5c5a1--