Introducing myself and my interest in ruby

[Robert Klemme]

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

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



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

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

 

[Charles Comstock]

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

Currently it does not ever hit bytecode at all, it just interprets using
the stack as near as I can tell.

Charles Comstock

 

[Nicholas Van Weerdenburg]

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

 

[Robert Klemme]

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

It's not the complexity of the statement but the dynamic. How should a
compiler compile something that isn't known until runtime?

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.

That might work.

Regards

robert

 

[Lothar Scholz]

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

No. Simply grep through the 1.8.1 standard library and you see that
it is used a lot in non trivial situations.

 

[gabriele renzi]

il 11 Jun 2004 07:59:05 -0700, (e-mail address removed) (Lothar Scholz) ha
scritto::

No. Simply grep through the 1.8.1 standard library and you see that
it is used a lot in non trivial situations.

yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.sendinitialize,src)

There should be interest in this kind of changes, apart from
compilation problems?

 

[Tom Copeland]

yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.sendinitialize,src)

There should be interest in this kind of changes, apart from
compilation problems?

Right on. Seems like if it an instance_eval usage can be safely
refactored to something simpler, it'd be a good thing.

Tom

 

[Mark Hubbart]

il 11 Jun 2004 07:59:05 -0700, (e-mail address removed) (Lothar Scholz) ha
scritto::


yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.sendinitialize,src)

There should be interest in this kind of changes, apart from
compilation problems?

Would instance_evals (assuming they take blocks) really be that big of
a problem? The way I see it, as long as it just takes a code block,
that part is compilable; all it takes is a change of the 'self'. But if
it takes a String, that must be compiled into code at runtime, and...

cheers,
Mark