Re: intralingua

[Paul Kienzle]

On Nov 8, 2005, at 3:11 PM, John W. Eaton wrote:

> On  8-Nov-2005, Paul Kienzle wrote:
>
> | The alternative approach is to target a common underlying object 
> system
> | for all the languages that you are using.  With introspection you can
> | make the compiled R methods directly available to Octave.  You can 
> then
> | install the compiled R modules and make them available directly to
> | Octave.  Since they are compiled, you do not need the R interpreter
> | available to use them.  More importantly, once somebody does the work
> | of wrapping e.g., the multivariate normal distribution functions in 
> R,
> | they are immediately available in Python and Octave.
>
> Octave has a large run-time library written in a mixture of C++, C,
> and Fortran (plus the scripting language code).  The run-time library
> handles type dispatching for operators at run time.  How does this
> work with something like Mono?  Can you link to the existing run-time
> libraries, or do they have to be rewritten for the virtual machine?

You can link with native libraries:

        http://www.mono-project.com/Interop_with_Native_Libraries

> Do variables in Octave live in its run-time system or in the Mono
> interpreter (or does that question even make sense)?

I wrote some code to test calling native libraries with dense
vectors.  They act like they are pass by reference (at least on
the Mac OS X mono implementation I downloaded today.

The main advantage of interlingua is that we would have a common
implementation of basic numeric types (vector, matrix, arrays,
sparse) living in mono which we could operate on in any language.

There are potential stumbling blocks, such as 1-origin index
vectors in octave and named rows in R, which will require thought.

I don't know how easy it will be to implement dynamic typing,
but IronPython shows that it is possible and it can be fast.

> Currently, Octave's parser and run-time are not completely separate,
> and the interpreter runs by walking the parse tree.  Generating code
> for some other kind of virtual machine from the parse tree should be
> possible, but will require some work.

Indeed.  I didn't mean to suggest this was trivial.

Since mono is strongly typed this is just as much work
as translating into C.  FWIW, a simple for loop is about
300 times faster in mono than in Octave.

Support for eval would require a complete octave parser
available at runtime.

> I agree that the best path for hooking scripting languages together is
> a common virtual machine rather than a collection of bi-directional
> links for each pair of languages.  I think RMS proposed Guile for this
> purpose about 11 years ago, but there has never been sufficient
> momentum behind Guile to really get things going, and as far as I
> know, there has never been a successful translator for any language
> that targets Guile.

Yes, because then we don't have to drop down to C to share code
between Octave and R.

> Are the efforts for other languages closely linked with the core
> languages?  How are updates to the Python internals (for example)
> tracked by the project that implements Python for .Net?  Are they
> implementing their own system from scratch?  How will the systems stay
> in sync?

Many of them start from scratch.  Some of them use the existing
language via external calls.

> For real success, I think these projects must be closely integrated,
> otherwise code that will work in the standalone system could fail
> or produce different results in the Mono/.Net system.

Agreed.

There are other problems.  For example Python extensions
generally do not work with Jython because the binding to the
C libraries is different.  Doing bindings automatically with
a tool like matwrap rather than coding them directly would
eliminate this problem once a C sharp wrapper is written.

Another concern is that submarine patents in the CLI and
CLR will kill mono once it starts to take off and probably
take Parrot out too.

- Paul



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------