"Mark Hubbart" <discord / mac.com> schrieb im Newsbeitrag
news:B54D2C2E-694A-11D8-8CCB-000502FDD5CC / mac.com...
>
> On Feb 27, 2004, at 8:24 AM, Robert Klemme wrote:
>
> > The question is, how attractive would this subset be?  I mean, there's
> > a
> > lot of code around that relys on beeing able to use eval and friends.
>
> I understand that. The attraction would not be that you can just
> compile any previously written code, but that you can code something
> *new* using the subset, and compile it. The compilable subset (call it
> cRuby) wouldn't be competing with Ruby, but C, C++, etc. For most
> things, one would still use good 'ol Ruby :)
>
> What cRuby *would* be useful for:
>   - Writing shared libraries that people programming in other languages
> could use
>   - Creating multi-platform apps that don't require a Ruby installation
>   - Avoiding C/C++ at all costs :)

I can understand why someone would want to do that. :-)

> Some projects simply *require* using a compilable language. I have not
> yet found a compilable language that is easy and fun to use. cRuby
> could fill the gap there.

I see.  So someone should start defining the sub set so we can see a bit
clearer where this leads.  AFAICS these are not in the subset:

#eval
#instance_eval
#module_eval

Maybe we would want to remove these as well:

#extend
#define_method

> >> IIRC lisp has eval() too, and there are plenty of compiler out ther
;)
> >
> > But not all of them compile to native.  GNU CLISP compiles to byte
code
> > AFAIK.
>
>  From the CLISP manpage:
> "Invoked with -c, the specified lisp files are compiled to a bytecode
> that can be executed more efficiently."

Btw, I guess this is what - at the moment - Ruby does, too, isn't it?

>  From my (very limited) experience with it, it doesn't seem that lisp
> has an eval statement, so much as lisp *is* an eval statement :)

:-)

> > Dunno what the native compiling compilers support, basically
> > you'll have to include the compiler in the runtime.
>
> Which is the reason for the language subset - within the subset, there
> would be no need for including the runtime; it could just be compiled
> to machine code.

I'm wondering how much performance that will give us since I am under the
impression that due to the highly dynamic nature of Ruby still a lot of
interpretation has to be done at runtime.  Unfortunately we won't know
prior to realization of the Ruby compiler. :-(

The other thing that adds to my scepticism is that there's a general trend
in computer languages towards managed code and VM's (Java, C#, clisp?,
....) and I guess there's a reason for that.  Maybe it's better to extend
the Ruby interpreter towards an intelligent runtime system like the Java
VM (or use that as an underlying system if possible).

> >> I bet you could write a compiler from ruby to at&t asm and let GAS do
> >> the rest :)
>
> Back when I was using perl, I checked out their Perl->C project. It
> could translate perl code into c code.  Problem is, it was trying to
> make it so that *any* valid perl code, including evals, could be
> translated. A simple "hello world" would get translated into a few
> thousand lines of C code. :)

Apparently they made the -v switch default. :-))

Kind regards

    robert