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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
