Hi all,

General ruby-talk comment: After a short vacation on Madeira I'm back and
impressed on the amount of traffic on ruby-talk. Seems Ruby has started
generating press and attracting new developers on a larger scale. Good for
all!

> Text -> Ruby Object nodes -> Ruby Visitor -> 
>                              Ruby machine code generator.
> 
> (ie. A Ruby compiler!)
>
Yeah, but please note that you probably need to link in a Ruby run-time
system similar to libgcj (http://sources.redhat.com/java/index.html) for
threads and GC for example.

I guess it would be wise to do the (I'm sure we'll want/need one) Ruby
complier as a front-end to gcc so that we can generate machine code for
the many systems that gcc supports. Any more ideas on Ruby
compiler? Interested in investigating this? I strongly think that we will
need this and I'm willing to dedicate some time to it. However, even
though I know the basics of compiler construction I haven't done much
pratical work so any help/ideas/links appreciated.

> Text -> Ruby Object Nodes -> Ruby Visitor -> Ruby Pretty Printer
> 
> Text -> Ruby Object Nodes -> Ruby Visitor -> 
>  * Ruby Profiler.
>  * Coverage tools. 
>  * Debuggers. 
>  * Refactoring Transforms. 
>  * Language sensitive IDE's.
>  * Analyses and metrics of how programmers program.
> 
I agree with John that this would be a very promising/interesting way to
go and strongly encourage you guru's to investigate different approaches
before committing to a particular strategy for Ruby 1.8 and on. However,
note that they need not be mutually exclusive
(ie. Text -> RubyObjectNodes -> Visitor -> RubyByteCode internally and
exposing RubyObjectNodes for John's and others "back ends"). Or is
translator speed crucial/major design criteria?

Regards,

Robert Feldt
feldt / ce.chalmers.se