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 :)

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.

>> 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."

 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 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. :)

--Mark