Hacker News new | ask | show | jobs
by dragonwriter 3976 days ago
> Everyone who ever tried implementing any ML-like language on top of JVM failed miserably.

How is "ML-like" defined here? AFAIK, Haskell is usually considered "ML-like", and Frege is a Haskell dialect implemented on the JVM.

1 comments

Haskell is nowhere near an ML-like language, it's lazy, while ML is eager. And Frege is nice and all that, but it's very far from being efficient, nothing close to F# performance.
I don't think you can say "Haskell is nowhere near an ML-like language" based on just lazy vs eager evaluation.

See here[0]:

> Since Haskell is inevitably an ML (descending from Lazy ML) derivative, one might begin by pointing out the similarities:

    - First-class support for algebraic datatypes (disjoint unions)
    - Pattern matching on primitive and custom values
    - Arbitrarily higher order functions
    - Type synonyms
    - Hindley-Milner Type Inference
    - Parametric Polymorphism (define arbitrary Functors etc.)
    - Ad-hoc polymorphism (Haskell through type classes, SML through modules)
    - scorn of inclusion polymorphism (sub-type relations, a la object-wise inheritance)
    - Monads (and other exotic algebraic structures)—"Haskell has monads" is a common claim of superiority, but the reality is that at the language level a monad is nothing more than an abstraction pattern, and hence every language (can) have monads. Including a monad or not in any given language is a library-level decision.
> While the bread-and-butter language features may be similar, building software in Haskell vs SML is actually quite a different affair:

So we can see a lot in common there.

0: http://www.quora.com/What-are-the-key-differences-between-Ha...

> based on just lazy vs eager evaluation.

It's not "just", it's fundamental. We're talking about an efficient implementation, remember? And therefore the underlying execution semantics is the single most important thing for classifying languages. The rest that you listed is very high level, consider it syntax sugar. It is all lowered down long before any of the important optimisations start to kick in.

> So we can see a lot in common there.

Not that much. Just think of the deeply fundamental difference between SECD and, say, STG.