From: Ryan Davis <ryand-ruby@...>
Date: 2008-10-27T17:30:37+09:00
Subject: Re: ruby_parser 2.0.0 Released

--Apple-Mail-21--171558361
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit


On Oct 22, 2008, at 23:33 , Mike Gold wrote:

> This is amazing work.  The Ruby collective superorganism thanks you.

thanks!

> Since parse_tree is pure ruby, and is therefore platform-independent  
> and
> ruby-implementation-independent, I suppose my default choice is
> ruby_parser over ParseTree.  Is there any reason to use ParseTree
> instead of ruby_parser, other than perhaps speed considerations?

That's certainly the direction I'm going in for my tools. The only  
reason to use PT over RP besides speed is getting sexps from procs and  
other instances (methods, modules, classes). But most of the projects  
that used to do that (Ambition, etc) are weening off of it for various  
reasons. We don't have a migration solution for 1.9 at all, and I  
don't see anyone coming up with one anytime soon.

> I've not used this stuff before, so pardon my ignorance.  I can make
> sexprs from ruby, and I see ruby2ruby which will convert back to ruby.
> However is there a way to execute sexprs directly?  Or is that  
> something
> rubinius will do?

rubinius doesn't execute sexps directly. It complies them into  
bytecode and then the VM runs that. It is certainly possible. That's  
what ruby (<1.9) does with the internal ASTs.

> The possibilities boggle the mind.  In principle I can write a Lisp
> program which executes the sexpr output of parse_tree.  Now I have
> another Ruby interpreter.  And if it's SBCL, I can generate an
> executable out of that.  Now I have a stand-alone ruby interpreter
> executable.  For the platform-specific stuff, a single Lisp
> implementation would need to be chosen (probably SBCL).

Absolutely. See what Luis Lavena has done with nekovm:

   http://blog.mmediasys.com/2008/10/19/experiment-ruby-to-neko- 
possible/

Absolutely rad stuff, and probably only took a couple hours of work  
for the PoC.

> And then there is the possibility of ruby macros.  I do see a
> newly-created defmacro project on rubyforge, however it's currently  
> just
> 30 lines of code.  Do you have any suggestions on what places to look
> for this kind of thing?  I want to be sure I'm not reinventing or
> co-inventing the wheel.

There have been a few. Caleb just announced one for his parser red- 
parse, but I couldn't get it to work. In that thread you can find  
these as well:

http://blog.drewolson.org/2008/06/ruby-and-macros-experiment.html
http://weblog.raganwald.com/2008/06/macros-hygiene-and-call-by-name-in-ruby.html

> As a practical example, suppose I want to take an .rb file and
> surgically remove all calls to Kernel#log.  That shouldn't be hard,
> right?  Now I need to set up a separate "compilation" phase,  
> assuming I
> want to keep my Kernel#log calls in the source.

No, it isn't hard at all... and doesn't even require anything as  
"scary" as macros. A simple SexpProcessor + ruby2ruby + eval will  
suffice to preprocess (or post... you can do all of this stuff on the  
fly) the code.

class StripLogging < SexpProcessor
   # ...
   def process_call exp
     return super unless exp[2] == :log
     s(:nil)
   end
end

that would prolly do it... with some extra stuff.

> Once that's done, here comes defmacro.  The compilation phase looks  
> out
> for defmacro, and does an inline substitution according to whatever
> rules we decide.  The next step is to make a post to comp.lang.lisp
> saying, "suck it!".

um. the lispers (and smalltalkers) still have a few (actually, more  
than a few) things on us. :)


--Apple-Mail-21--171558361--