Something I don't understand is why the Java PTB have no plans to fit dynamic objects into the Java language. It wouldn't take much to accomplish that, at least conceptually. Seems odd to add the feature to the JVM and not the language.
On Nov 26, 8:45 am, [email protected] wrote: > Selon Jon Harrop <[email protected]>: > > > > > On Wednesday 25 November 2009 16:57:51 Alexandru Nedelcu wrote: > > > Hi, > > > > I'm a rookie looking to implement a language for fun & profit :) > > > > I want to know if there are any publications on efficiently mapping > > > the ML type-system to Java, like tuples, unions, closures ... or like > > > implementing generics through reification or through code- > > > specialization (I can't think of a reason why not, but I don't have > > > the experience). > > > > Or any articles on implementing static language features on top of the > > > JVM (I can see there's a lot of talk on dynamic features in the Docs). > > > You might also appreciate the OCamlJava project that tries to run OCaml on > > the > > JVM: > > > http://ocamljava.x9c.fr/ > > > To the best of my knowledge, this project is also almost entirely unused. > > It is quite true that only few people showed interest for OCaml-Java. > One major hurdle is that the project is plagued with performance problems. > You know what happens when an holiday project turns into a codebase with > more than 100k lines: early design decisions are paid with cumulated > interests ... Plus, my mantra has always been "first make it work, then > make it fast". > > However, I am closely following this list to gain a better knowledge of > the JVM, and hopefully a version with decent performances should be available > for mid-2010. > > As an answer to the original poster, I would like to point out that > some JVM features that are advertised as "for dynamic language" will > also be hugely beneficial to "static" languages of the ML family. > Two short examples: > - the memory profiles of both language categories are quite similar: > lot of small, short-lived objects are allocated, and hence a > garbage collector tuned for "dynamic" languages will also be a huge > win for "functional" languages; > - the "invokedynamic" instruction is a must-have for reasonable > implementations of "dynamic" languages, but "functional" languages > will also leverage its power to implement closures far more efficiently. > > As a conclusion, I would say that, although I am strong advocate of "static" > languages, my understanding of the current situation on the JVM is: > "what is good for dynamic languages is indeed also good for static > functional > languages". > > Xavier Clerc -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
