Re: Compiling Ruby to Native Code?

On Monday 12 August 2002 18:58, you wrote:
> 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.  ...
> 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 have some things I want to do (quite a large number, actually) that can be 
completely specified at compile time.  Others where I at least know the type 
and length of the parameters.  And others where things are pretty open, where 
I can be reading a piece of data, and be expecting the data to tell me itself 
whether it's a number, or a word definition, or a picture, or...  When it 
gets in, I want it to be living in an object of the appropriate type.  So far 
the languages that I can see how to do this in are C, Python, and Ruby.  And 
in C it's too clumsy for words.  But I was taught that when you can specify 
things at compile time, then you should do so, because it facilitates both 
efficiency and error catching (and correction).

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

It's been awhile since I looked at OZ, perhaps a year, so the details are 
fuzzy.  I know that I ran into the "Pickle functor", but I also know that I 
couldn't quickly figure out how to use it in the way that I wanted.  (Perhaps 
it has trouble with random IO?  A part of what I want to do is build an ISAM 
file with accompanying indicies.)
>
> ...
>
> 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.

That's certainly the case (though I would argue that some of them, e.g., 
Basic, are poorly designed even for their intended areas of use).

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

Right you are.  I really like Ada, but it's basically impossible to do 
anything flexible with it.
>...
> Efficiency gains of compiled vs. interpreted code are often overstated,
> ...
I had thought that, and then I encountered Java and Visual Basic.  That 
renewed my belief.

>
> 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.
Sort of like the inverse of "Languages for the JavaVM"?

>
> %% 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!

You were totally right.  I not only love it, I also hate it.  But at least it 
doesn't have those $#%#^%& pointer casts that C and C++ have.

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

That's why I was hoping that it might be reasonably simple.  Perhaps one could 
just pretend that the called module was a C module.  Or at worst have a 
simple C module that just acted as a delegator.  But I wouldn't be the one 
who wrote such a thing.  Still, i understand that soon after gcc3.0 is 
released, that gnat is expected to be rolled into the compiler collection.

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

That sounds interesting, but I'm having trouble visualizing what is going on.  
Still, it might make a lot of Java GUI builder output available at not too 
much additional cost.
>
> ...
> My point is: Where there's a will, there's a way. :)

The problem is, which is the best one, since there are usually dozens.
>
> Sincerely,
> Bob Calco
>...