From: Nicholas Van Weerdenburg <nick@...>
Date: 2004-06-11T13:00:57+09:00
Subject: Re: Introducing myself and my interest in ruby

A compiler could attempt to translate evals into other constructs. I 
think most are simple enought to do that.

Open classes and self-modifying code are another problem. Conceivable, a 
ruby class could be be redefined a 1000 times during a programs 
execution. Still, most cases are probably addressable by the compiler.

5 mb is a big hit- maybe a special minimal gap-interpreter could be 
included that handles some of the weirder not-easily compilable cases?

Nick

Sean Russell wrote:

>Hal Fulton wrote:
>
>  
>
>>I like the way you're thinking. I believe the principal reason a Ruby
>>compiler (or C translator) doesn't exist is simply that no one has
>>written one.
>>    
>>
>
>There are a few severe roadblocks to implementing this, the biggest one
>being eval().  To support eval(), an executable needs access to the entire
>Ruby interpreter.  This interpreter can be in the form of a dynamic
>library, but then there isn't much difference between installing Ruby and
>installing the interpreter library.  Or, the interpreter can be bundled
>with the executable, which adds at least 5MB to the size of each executable
>and still doesn't address the various library dependancies that can't be
>discovered because of code like:
>
>        class Foo
>                def initialize
>                        eval( "require 'gtk'" )
>                end
>        end
>
>eval() is just one issue that confronts any attempt at creating an
>application that converts Ruby to (C|Java|Native code|whatever), and I'm
>sure there are others.
>
>Which makes me think that a great thing to have would be a document that
>identifies all of these cross-implementation difficulties.  Maybe we could
>come up with a "portable Ruby" specification -- a minimal description of
>the set of Ruby features that can be implemented without having access to a
>Ruby interpreter.
>
>  
>