ANN: ParseTree 1.3.3 and ruby2c 1.0.0 beta 1

[Ryan Davis]

It can't (and won't) translate dynamic code. Period. That is simply
not
the intent.

[This is just my personal opinion, and is not meant to be mean]

I guess the name Ruby2C and its goals are not well choosen, for in my
opinion it makes no sense to rely on type inferal and conversion to
C-types in a inherently dynamic language like ruby. Furthermore, it is
very restrictive subset you choose.

While I respect your opinion, your statement is loaded. You admit (in a
later email) to having read our propaganda, so you know why we chose
type inference and conversion to C types and you know that the subset
we chose is restrictive on purpose (although we are working on opening
that up as much as we can, there is still only so much that we can do
with a static subset of ruby). You also know _why_ we are doing this,
so I'm terribly confused why you think that both the name "ruby2c"
(which is what it does, for a subset of ruby) and the goals are not
well chosen. I don't think your bullet points below do a very good job
of explaining that and I'd like to understand your opinion more.

In your example, you end up with a method like

Classes compiled in such a way:

* Need a very restrictive wrapper to be called from ruby

I'm not sure I understand this point, but I'm guessing it is just a
matter of nomenclature.

* Methods have to be final
* No dynamic binding
* Explicit type conversion before calling the method

Yup yup. This is exactly our intent and I think we are right for
choosing it.

* Cannot be extended from ruby

Do you mean the code that we translate to C cannot be extended? If so,
then yes, that is our intent, in the exact same sense that ruby's C
code cannot be extended (in C) very easily (but then can be extended in
ruby).

* Do not use the ruby C framework

Well at this point, we have only scrapped up a rather poor translation
to C, and whether we do completely generic C, or ruby extension C, or
_both_ is up in the air. Since we architected the tools using a
pipeline with a very clean architecture, it is very feasible (and EASY)
to do both and have two different ends of the pipeline, depending on
what the user is trying to translate to. I'll be working on some
doco/propaganda to illustrate that in the near future because we
haven't made that clear at all.

Smalltalk was mentioned in the BLOG as an example of a language, where
most functionality is written in the language itself, but:

In Smalltalk, altough most things are written in Smalltalk itself, they
rely on a VM, which is able to interpret all kinds of smalltalk code. I
think this approach, which maybe YARV may realize, is much more
appropriate for a dynamic language like ruby.

Yes, Smalltalk relies on a VM. And in at least the case of squeak (but
I also think a couple of others--but minor ones at that) the VM is
written in a static smalltalk subset and then translated down to C. The
product of which made the squeak team MUCH more efficient and able to
port their code to more platforms faster than they'd been able to prior
to having the system written entirely in smalltalk.

But then again, maybe I did not understand your intent.

I'm pretty sure you do, based on email from you that I haven't
responded to yet.

 

[Ryan Davis]

On Wed, 02 Feb 2005 20:40:39 +0900, Alexander Kellett wrote:

I understood this point. So RubyC would be a better name (i.e. a high
level description language for C with automatic type inference). If
this is the _main_ goal, i can see some benefits. Also, you would
have to supply some low-level IO mechanism if you want to write e.g.
hardware related extensions.

I'm not going to play semantics here. I don't see any real distinction
between "RubyC" and "Ruby2C" so I'm just going to leave it up in the
air as a moot point. I will point out that in your own previous email,
you referred to the C API in ruby as "ruby C". Regardless, the project
has been named and I think it is going to stay that way.

 

[Ryan Davis]

I had read it, but I missed that page at the end. Sorry for that.
But inlining a method, and converting a whole program to plain C (w.o.
the overhead from dynamic method dispatch etc.) are two different
things. For my defense: the latter is what you promote in the first 25
slides.

Yes, inlining and full translation of an application are two different
beasts. Luckily, we aren't limited to just one of them, and we can use
both goals to supplement each other's efforts with about 2/3 overlap.

Ok, this sounds very ambitious. The ruby core is well written and it's
hard to write an equivalent substitution.

I totally totally agree. Babysteps. Or, as an excellent boss of mine
often said: big alligators, small alligators, swamp.

And the VM part: It think it is very hard to write a fast VM in C. A
Ruby2C translator which generates a fast VM sounds like a miracle.

As I've pointed out before, this isn't as hard as you make it out to
be. Granted, we have a much different road to travel than squeak. But
it has been demonstrated as not only possible, but beneficial.

Anyway, good luck - I'm sure it is a lot of fun.
At least you do not have to write in C[1]

[1] http://gnu.de.uu.net/wic.html

I'm on a bus right now, but I'll check that out as soon as I can.

 

[Ryan Davis]

[1] http://gnu.de.uu.net/wic.html

Having now read this, I officially hate you.