On Feb 2, 2005, at 3:00 AM, Benedikt Huber wrote:

> On Wed, 02 Feb 2005 10:56:09 +0900, Ryan Davis wrote:
>> 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
>> void hello1(long param) { .. }
>
> 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. :)

--
ryand-ruby / zenspider.com - http://blog.zenspider.com/
http://rubyforge.org/projects/ruby2c/
http://www.zenspider.com/seattle.rb