Mixing code in different languages (was: Re: Firefox and Moonlight (Mono) "Free Software" Status?)

[Richard W.M. Jones]

On Sat, Jun 07, 2008 at 02:21:23PM -0400, Colin Walters wrote:
> > lack of dynamic
> > method invocation,
> What does that mean?

JSR 292 (http://jcp.org/en/jsr/detail?id=292) and the invokedynamic
bytecode.  If I understand it correctly, it lets you call a method
where you don't know the method type until late at runtime.

> Where are you getting this list from?

Actually from Xavier Clerc, the extraordinarily talented author of
ocamljava, and from looking at the codegen in ocamljava.

> > duck typing, multiple inheritence, 64 bit ints, immediate objects, and a
> > bunch of other stuff.
> 
> It's not clear to me those are fundamental tradeoffs vs just not implemented
> for some reason - e.g. what would blocking using "long" for 64 bit ints?

OK, so that bit didn't come out right.  Ocamljava implements OCaml as
if it was running on a 32 bit processor.  I admit I'm not entirely
sure why this is, but it creates some annoying limitations (string
length is limited to 16 MB in particular, which sucks).  Of course
there is an int64 type.

> Anyways, the point I wanted to refute is this:
> 
> > > Free software dropped the ball
> > > on this (Parrot), and Mono/.Net is the only widely available
> > > implementation of this idea.
> 
> And I believe that's been done.

Actually I think I stand by my original statement all the more.  Free
software _doesn't_ offer an alternative.  OK, it's possible to run
some mixed languages on the JVM.  But it's not practical -- you can't
practically write a Jython library called by an OCamljava main program
[substitute your favorite languages here as appropriate].  Mono/.Net
_is_ the only widely available practical implementation
(unfortunately).

On a more constructive note though, what would it take?  I think your
comment here was very insightful:

> There is largely never going to be a clean automatic way to do
> cross-nonnative language calls.  Here by nonnative I mean languages which
> were designed to run on a custom runtime (not JVM/.NET).  For example,
> Python strings are immutable, Ruby strings are mutable; if you were to pass
> a Python string into a Ruby function it couldn't act exactly like a Ruby
> string.  The corner cases get even more bizarre once you start to look at
> more languages and more data types.
> 
> The more compelling long-term direction behind the JVM and .NET is taking
> the *good* things from different languages (e.g. OCaml's type inference and
> pattern matching, Python's clean syntax, generators) and throwing out the
> bad stuff (non-Unicode strings, bizarre/broken class models) and creating
> new languages that are native to the runtime; Microsoft has done this to
> OCaml with F#, Groovy is a much nicer and more strongly integrated dynamic
> language than Python/Ruby, etc.

So what's the answer here?  Do we:

- Have a big effort to root out prior art for every patent MSFT has
applied for in the past 17 years so we can prove Mono is
non-infringing?

- Work on ironing out all the practical problems with the JVM, perhaps
_forking_ the JVM and adding our own bytecodes if Sun is slow or
non-responsive?

- Kick some resources towards making an open source project like
Parrot work and then a huge amount more resources towards porting all
the languages to it?

- Define C as our "common runtime" and make language <-> C generators
for everything that work really well (basically what I did when I
wrote http://merjis.com/developers/perl4caml)?

This is a serious question.  Certain groups of users I've talked to
like OCaml, but don't want to write whole programs in OCaml (or want
to use their existing libraries with it).  Unfortunately for everyone
F# is being seen as a practical solution to their problem, which means
they're locked into a proprietary language on a proprietary operating
system.

As a user of a minority language, I'm keenly aware of this problem and
I've been thinking hard about it for many years now.  Perl4caml was my
initial answer to the problem (several years ago) that OCaml lacked
lots of libraries [use perl4caml == access all of CPAN].  Wish I had a
good answer to the general question though.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora