From: Eric Hodel Date: 2005-02-03T03:52:11+09:00 Subject: Re: ANN: ParseTree 1.3.3 and ruby2c 1.0.0 beta 1 --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--