--Apple-Mail-39-214053251
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 02 Feb 2005, at 03:00, 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.

We're only human.  Getting Ruby2C as far as it is has been a very large 
investment of our time, and I think its cool that we have any type 
inferencing at all.  We'd like to be able to translate more dynamic 
things, but it will be easier if we have other eyeballs on this helping 
us out.

You should, however, check out the propaganda document if you haven't 
already, it gives a much better idea of our goals:

http://www.zenspider.com/~ryand/Ruby2C.pdf

> Furthermore, it is very restrictive subset you choose.

That's because we haven't yet had the time to make it any larger than 
it is.  We are releasing because we want to recruit people to help us 
expand that subset.  (And to do other things, check out the propaganda 
document above.)

Instead, we focused on having a very helpful tool-chain and an 
extensive suite of tests.  These have helped us do very powerful things 
to the Ruby AST in a very short amount of time.

> 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
> * Methods have to be final
> * No dynamic binding

Check out the propaganda document...  There's an interesting slide near 
the very end.

> * Explicit type conversion before calling the method

You have to do this when writing wrappers to C code anyhow, but again, 
read that propaganda document.

> * Cannot be extended from ruby

The propaganda document gives a good workaround for this, and is a good 
example of the 90/10 rule.

> * Do not use the ruby C framework

But they can!  See the propaganda document.

Remember that extension writing is *not* our goal, it is more of a side 
benefit that Ruby2C gives you.

> 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.
>
> But then again, maybe I did not understand your intent.

You catch it exactly, but you miss how our tool fits into what Squeak 
Smalltalk does.

You could write all of the code in Ruby's core, even the VM, in Ruby.  
Then you translate the absolute minimum to C you need automatically 
with Ruby2C (eventually, just the VM).

In order to get there, however, you need to have Ruby2C working in 
general.

Ruby2C is better suited to the C side of things, Array, Hash, String, a 
VM, than it is to the Ruby side of things, because the C side of Ruby 
is much less dynamic.  These things can all be written in the Ruby2C 
subset then translated automatically.  As Ruby VMs get faster, 
eventually Ruby2C will no longer be necessary, and hopefully will only 
be used on the Ruby VM itself.

-- 
Eric Hodel - drbrain / segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04

--Apple-Mail-39-214053251
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCASEkMypVHHlsnwQRAiZGAJsHMm9xBjrShmtdePUNy1YBdp2HBACfROCP
hopvr4VIByL/pHffr8zxkHM=
=vVYZ
-----END PGP SIGNATURE-----

--Apple-Mail-39-214053251--