From: Rocky Bernstein <rockyb@...>
Date: 2010-12-13T09:34:30+09:00
Subject: [ruby-core:33700] Re: Towards a standardized AST for Ruby code

--000e0cd2531cefd48f04973fdd01
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 12, 2010 at 7:09 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:

>
> On Dec 12, 2010, at 08:54 , Haase, Konstantin wrote:
>
> > On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:
> >
> >> The only down side at the moment is that RubyParser does not support
> >> 1.9 syntax.
> >
> > Also, such a parser cannot be used to inspect a live system (accessing
> the AST for a method or closure, for instance) unless it would be possible
> to access the source code of those (as in JavaScript). Therefore it cannot
> be used for say partial evaluation in a live system (pypy does this for
> generating extremely fast code).
>
> I have asked until I was blue in the face for 1.9 to be extended w/
> optional live AST access. It would make really powerful tools available to
> all rubyists across 1.8 and 1.9. Despite this desirable fact, it has been
> rejected time and time again.
>

I have been using ("maintaining" is probably too strong a word) a patched
version of Ruby 1.9.2 which supports debugging better. I haven't done this
yet, but I will probably  keep the AST around precisely because folks have
requested for it, and to be able to use MRI 1.8 tools that currently work on
ASTs.

Given the way things are right now, it is my belief that it is very
difficult to have one version of Ruby YARV 1.9.x that both performs
extremely well, is flexible in implementation choices, yet has all of the
"live" introspection facilities one might have say in a Smalltalk system.
 Having two interpreters based on the same code base, while not ideal or
easy, seems to me at least more doable.

On  the other hand, I do believe that in the rubinius implementation it is
possible to have one interpreter/system which suits both competing needs of
performance and live introspection. I believe this because in a sense
rubinius *is* already two implementations: a Ruby interpreter plus a JIT for
it.


> I've gotten rather lame responses on why it is undesirable (usually
> memory--which seems moot if the AST is only available given a cmdline flag
> or other opt-in only option).
>
> I've since given up asking and left it to others to ask. (Like at rubyconf
> 2010's "ask matz" session--thank you!)
>
>
>

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

<br><br><div class=3D"gmail_quote">On Sun, Dec 12, 2010 at 7:09 PM, Ryan Da=
vis <span dir=3D"ltr">&lt;<a href=3D"mailto:ryand-ruby@zenspider.com">ryand=
-ruby@zenspider.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
<br>
On Dec 12, 2010, at 08:54 , Haase, Konstantin wrote:<br>
<br>
&gt; On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:<br>
&gt;<br>
&gt;&gt; The only down side at the moment is that RubyParser does not suppo=
rt<br>
&gt;&gt; 1.9 syntax.<br>
<div class=3D"im">&gt;<br>
&gt; Also, such a parser cannot be used to inspect a live system (accessing=
 the AST for a method or closure, for instance) unless it would be possible=
 to access the source code of those (as in JavaScript). Therefore it cannot=
 be used for say partial evaluation in a live system (pypy does this for ge=
nerating extremely fast code).<br>

<br>
</div>I have asked until I was blue in the face for 1.9 to be extended w/ o=
ptional live AST access. It would make really powerful tools available to a=
ll rubyists across 1.8 and 1.9. Despite this desirable fact, it has been re=
jected time and time again.<br>
</blockquote><div><br></div><div>I have been using (&quot;maintaining&quot;=
 is probably too strong a word) a patched version of Ruby 1.9.2 which suppo=
rts debugging better. I haven&#39;t done this yet, but I will probably =A0k=
eep the AST around precisely because folks have requested for it, and to be=
 able to use MRI 1.8 tools that currently work on ASTs.=A0</div>
<div><br></div><div>Given the way things are right now, it is my belief tha=
t it is very difficult to have one version of Ruby YARV 1.9.x that both per=
forms extremely well, is flexible in implementation choices, yet has all of=
 the &quot;live&quot; introspection facilities one might have say in a Smal=
ltalk system. =A0Having two interpreters based on the same code base, while=
 not ideal or easy, seems to me at least more doable.=A0</div>
<div><br></div><div>On =A0the other hand, I do believe that in the rubinius=
 implementation it is possible to have one interpreter/system which suits b=
oth competing needs of performance and live introspection. I believe this b=
ecause in a sense rubinius *is* already two implementations: a Ruby interpr=
eter plus a JIT for it.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I&#39;ve gotten rather lame responses on why it is undesirable (usually mem=
ory--which seems moot if the AST is only available given a cmdline flag or =
other opt-in only option).<br>
<br>
I&#39;ve since given up asking and left it to others to ask. (Like at rubyc=
onf 2010&#39;s &quot;ask matz&quot; session--thank you!)<br>
<br>
<br>
</blockquote></div><br>

--000e0cd2531cefd48f04973fdd01--