RE: Compiling Ruby to Native Code?

Charles:

[In RE: multiparadigm programming, some thoughts relevant to your remarks
follow...]

%% Charles Hexton wrote:

%% The problem that I have with many of those paradigms, is that
%% they don't easily support the idea of data files.  Particularly
%% of data files that may be looked at and changed in some other
%% language.  This seems endemic in the functional languages,
%% though, of course, the object oriented languages have their
%% problems with it also (as you know if you have ever tried to
%% keep a relational database in sync with a object oriented
%% program).  This is why marshalling was invented, and it's far
%% from perfect.  Only the procedural languages seem to have solved
%% this one, and that largely by not directly representing the kind
%% of structures that cause problems.

Well at the binary level most of the data types in all languages are
reducible to bytes, or some compound thereof; I'm not exactly sure I guess
what you mean. Oz for instance treats all serialized file system objects as
standard "pickles," and under the hood, being developed as it is in
templatized ANSI C++, it ultimately uses data structures that are quite
compatible with C/C++ and any language that has analogous data structures.
Not sure I understand your point here...

%% I assume that there actually are ways to address this in Mozart,

Yes, the Pickle functor. There are also some contributed funtors that handle
file system abstractions rather painlessly based on Pickle. Pickled "Files"
are URL based in Oz thus easily accessed over standard internet protocols as
URLs. And since Oz abstracts network protocols to a very high level, one
needn't worry about the specific file system on which a Pickle resides -
that's a low level detail dealt with by the Oz emulation VM, in much the
same way Java deals with file streams at an I/O level. Except the network
abstractions aren't as transparent in Java as they are in Oz.

%% but I wasn't able to discover them in the time that I allotted
%% for evaluation.  Other than that it looked quite interesting,
%% but that was such a large "but" that I never tried to implement
%% anything.  Ditto for Haskell.  Eiffel was quite interesting, and
%% I rather like it.  But some unnecessary choices (e.g., no
%% operation redefinitions with altered parameter lists) have
%% rendered it quite inflexible.  I've used it a bit, but you need
%% to be extremely careful to not name operations anything
%% reasonable, e.g. substring, because that will cause grief.
%% Instead use a name like substring_with_unspec_length.  Operator
%% overriding is quite basic to all other computer languages.  Even
%% Fortran 77 has what Eiffel considers a forbidden amount of
%% operator overriding (+ can be used not only on integers, but
%% also on floats, and between integers and floats, and ...).  So I
%% found Eiffel unreasonably clumsy, and for no good reason
%% (paraphrase" There can exist situations where the meanings of
%% different operations cannot be disabiguated by the type of their
%% parameters, e.g., point(x, y) and point(r, theta), so we must
%% forbid this choice."), and so in the language design the
%% operations are totally specified by the name of the operation.
%% (Perhaps C++ munges names to do this, but at least the
%% programmer doesn't need to keep track of THAT.)

Well, every language has its rationale, and the semantics of each language
is usually and quite rightly influenced heavily by the problem domain or
domains that its author had in mind originally when he/she invented the
language.

At the extreme end are languages like Eiffel and Ada, which have an explicit
reason for just about every feature and non-feature imaginable. (I would
hypothesize that if you like Eiffel with its "Design by Contract" paradigm
enforced by the compiler, you probably dig (or have love-hate relationship
with) Ada too, with its brutal compile-time type checking.)

%%
%% This is a great pity.  Most of the code that I do really is
%% statically determinable, so it would be nice to be able to
%% compile it to execute with the potential efficiency.

Efficiency gains of compiled vs. interpreted code are often overstated,
except in cases of heavy use of recursion, as for instance in mathematically
intense operations, i.e., involving 3D graphics. Even there, with a thin
extension interface to native graphic engine, it's rather hard to tell
whether C/C++ or Ruby, Java, etc. are at the wheel.

That having been said, one side project I'm working on to make it easier to
experiment with different object-code generators based on Ruby syntax is a
generic Ruby parser DLL, based on the parse.y file in the standard Ruby
distro, but modified to expose the hooks into the parser in a more generic,
back-end-neutral fashion through a DLL. Once operational, it should
theoretically be possible to write any number of backends for the parser: A
java bytecode generator, a C code generator, native assembly code generator,
.NET CLR generator, you name it. Any language that can interface to stdcall
C functions in a DLL or SO should be able, moreover, to make use of it.

%% Unfortunately, it usually needs to work with at least some
%% modules that aren't.  Currently the only choice seems to be C
%% (and probably a few C mimics .. I wonder how I would link Ruby
%% with Ada95[gnat]?).

Aha! I knew you liked Ada!

Well, GNAT specifically is a variant of the GCC compiler, and as such it
boasts (and delivers) complete binary interoperability with GCC C/C++. I
would guess a binary extension between Ruby and Ada would be fairly
straightforward, assuming it was really something somebody wanted badly
enough to invest some time in developing.

I'm currently working on such a binary interoperability package between Ruby
and Java, which I'm calling Arubica, using the Ruby C API and the Java
native interface. With Arubica, you can create an instance of the Ruby
interpreter and call into the Ruby ObjectSpace to call existing Ruby modules
and define new classes and modules on the fly, in Java. And vice versa: you
can create an instance of the JVM and call into a custom class loader and
create pure Java objects on the fly.

This is a very different approach than that of JRuby/Jython. The original
motivation is to enable testing of pure Java objects in pure Ruby, but the
bidirectional interoperability capability seemed worth it, while I was at
it. The design is nearly complete, but lots of coding remains, and I'm sure
more coding will result in redesign, as is only proper.

It's currently in early alpha, sometime in the next couple months I'll
release a version through RAA.

My point is: Where there's a will, there's a way. :)

Sincerely,


Bob Calco


%% --
%% -- Charles Hixson
%% Gnu software that is free,
%% The best is yet to be.