Yeti : an ML-derived language for the JVM | Hacker News Reader

Yeti : an ML-derived language for the JVM

linux.ee

Here is another way to run an ML-like language on the JVM:

http://ocamljava.x9c.fr/

It supports all of OCaml, but it seems complicated to get running along Java with the same sophistication as Yeti. For instance, it seems that one must use the "Nickel" tool to generate Java bindings, rather than simply using "#" for Java calls as in Yeti:

http://nickel.x9c.fr/index.html

http://linux.ee/~mzz/yeti/intro.html#using-java-classes-from...

It would be nice to see a section on "How is Yeti different from Scala?".

from a quick glance (only), and not being terribly proficient in either scala or ml, i would say:

- yeti appears to be quite a faithful port of sml to the jvm, while scala is perhaps best thought of as the bastard offspring of java and haskell.

- as a consequence, yeti is simpler and intended for programming in a functional style. while scala is much more complex and "object functional" (is that a recognised description these days?).

- the integration between java and scala appears to be somewhat cleaner than that between java and yeti (although both are fairly good).

- scala's type system is significantly more powerful. someone better educated than me can explain the difference in detail, but yeti seems to have just "simple" polymorphism, while scala has bounded types etc(1).

- scala also has a whole pile of tricks related to getting the type system to do things "implicitly" that is, well, i guess you either love it or hate it.

- yeti appears to be better than scala at getting optimised (ie not broken) tail calls to work.

- scala is baroque; yeti minimal.

- scala may be the future of java programming (which is good). yeti certainly isn't (which is a pity, imho).

- a lot of the above parallels the difference between ml and haskell (if you ignore the laziness part). these days, haskell is a bit of a monster; ml is significantly simpler (even ocaml).

(1) what happens with yeti when you have polymorphism and mutable containers? i have no idea. perhaps runtime type errors?

Regarding the last question: "what happens with yeti when you have polymorphism and mutable containers?"

In section:

http://linux.ee/~mzz/yeti/intro.html#type-declarations

"Variable (and argument) bindings are not polymorphic (it would make typesystem unsound), and therefore their type changes:"

For more details about this type unsoundness in ML, see the long version of "Relaxing the value restriction":

http://www.kurims.kyoto-u.ac.jp/preprint/file/RIMS1444.pdf

I'm not sure it's a particularly faithful port of ML, and particularly not SML. It doesn't really look anything like ML. It looks like a bit of a mishmash of syntaxes, if anything, so I'm really not sure what makes it "ML derived" any more than it is Python-derived or Algol-derived.

Here is a list of features that Yeti has that are either not in Python or not in Algol. That is, none of these features is in both Algol-60 and Python:

* static typing

* discriminated unions

* first-class functions

* immutability by default

* pattern matching

These are all present in both Yeti and SML.

Yes, Yeti is not SML, but I think it's much closer to ML and Friends than it is to any other language family, even Haskell or Scala.

Deleted comment

well, i brought sml into it originally. all i really meant was that it looked more like sml (+ java) than ocaml (if that makes any sense - yeti doesn't seem to have the kind of sophistication ocaml has for handling typed objects, for example). but i'm no expert - i'm happy to see people expand and improve on what i wrote.

Syntax is only half the picture. Semantics-wise, I'd say it's reasonably "ML derived".

"yeti appears to be quite a faithful port of sml to the jvm, while scala is perhaps best thought of as the bastard offspring of java and haskell."

Scala was arguably more influenced by ML than Haskell. It's really more of an amalgamation of different languages than anything else.

I think to say "haskell is a bit of a monster" you would have to qualify that you are talking about the current ghc haskell implementation. Haskell 98 seems like a realtively simple language (maybe Monads and laziness make it a little complex)

I don't see why this is Machine Learning -derived. Or maybe ML stands for something else here...

Edit: Thanks for clarifying. It is good to remember that there is other viewpoints :)

It is derived from the ML programming language (http://en.wikipedia.org/wiki/ML_%28programming_language%29). Other languages in this family are SML, OCaml, Scala, F#, and (more-or-less) Haskell.

http://en.wikipedia.org/wiki/ML_%28programming_language%29

Look up the ML language :-)

do is not fun

http://en.wikipedia.org/wiki/ML_%28programming_language%29#F...

Reply on news.ycombinator.com