4 ms·

I always had a beef with this paper; so many of the issues are much better solved in Haskell, yet he doesn't introduce it directly until he has something to cri

I always had a beef with this paper; so many of the issues are much better solved in Haskell, yet he doesn't introduce it directly until he has something to criticize. Unfortunately the critique reveal a very poor understanding. First point, lazy evaluation incurs a mutation when the whnf is reduced. However, this mutation occurs at most once and after that the value is immutable just like in SML. Furthermore, the update is not directly exposed to the programmer and thus the compiler can implement it in a way that works efficiently in the presence of generational GC. See the GHC papers on how. Second point, on polymorphic overloading he claims that Haskell "allow run-time resolution of overloading". Mark P. Jones and others have show how this overhead can be largely eliminated via partial evaluation applied to the type dictionaries. The use of polymorphic overloading is pervasive in Haskell code because it's incredibly useful so the "apparently small gains" is complete and utter nonsense. In many ways O'Caml is a better SML than SML, but Haskell, and especially the GHC variant, has a type system that is light years ahead of both. In the modern world there are many variations on the theme, but the language Rust (which borrows many ideas from these) might become the most popular yet. EDIT: typo

zootm 8y ago
I think it's worth noting that the paper is from 1992, where much of the work you reference (such as widespread use of overloading in Haskell) won't have existed yet. I don't think it's unreasonable to point out that some of the assertions didn't stand the test of time, but I've (maybe unfairly?) read your comment as critical of the paper despite context.
scscsc 8y ago
What are the "many" other issues (other than the two you mentioned in your comments)?
- FullyFunctional 8y ago
  A random sampling (with some overlap of already discussed issues): * A less verbose syntax (want examples?) and less bizarre syntax :) Clearly subjective, but IMhO Haskell is a lot cleaner * Constructors starts with uppercase, avoiding the issue the issue related to misspelled constructors (and allowing most editors highlight the constructor) * Type-classes allow for sane overloading of functions and operands, solving the int/float problem of SML, but extending far beyond just that. * As he mentions: the infix operator and the export from modules are both fixed in Haskell * Supports binary numbers (sure, it's a trivial library issue, but possible because of type classes allow extending the concept of numbers) * The polymorphic equality is solved in Haskell, again, with type classes, allowing us to define equality to any user defined type in a way that makes sense for it (including the set example) * List concatenation is right associative (he mentions SML's left associative @ as a problem) * SML's overflow on + problem are solved by not having overflow (j/k, Haskell lack of overflow on integers is a serious problem IMO, but other than making Int === Integer there's no easy solution).
  - scscsc 8y ago
    So you are agreeing with the author, since he is critiquing Standard ML (not Haskell). It is clear that the paper was influential, since Haskell does not have the shortcomings described.
    - FullyFunctional 8y ago
      Haskell predates the paper so no, I don't agree with your interpretation
grenadier21 8y ago
Partial evaluation of the viable strikes me as a very elegant idea! That way static dispatch just becomes a special case of virtual dispatch. It also reminds me of devirtualization optimization, and tangentially, how Rust does the opposite thing, by making boxed traits implement the traits, too, which makes dynamic dispatch a special case of static dispatch.
ernst_klim 8y ago
>In many ways O'Caml is a better SML than SML, but Haskell, and especially the GHC variant, has a type system that is light years ahead of both. Not true. Haskell does not have neither subtyping nor row and structural polymorphism for example.

zootm 8y ago

I think it's worth noting that the paper is from 1992, where much of the work you reference (such as widespread use of overloading in Haskell) won't have existed yet. I don't think it's unreasonable to point out that some of the assertions didn't stand the test of time, but I've (maybe unfairly?) read your comment as critical of the paper despite context.

scscsc 8y ago

What are the "many" other issues (other than the two you mentioned in your comments)?

FullyFunctional 8y ago
A random sampling (with some overlap of already discussed issues): * A less verbose syntax (want examples?) and less bizarre syntax :) Clearly subjective, but IMhO Haskell is a lot cleaner * Constructors starts with uppercase, avoiding the issue the issue related to misspelled constructors (and allowing most editors highlight the constructor) * Type-classes allow for sane overloading of functions and operands, solving the int/float problem of SML, but extending far beyond just that. * As he mentions: the infix operator and the export from modules are both fixed in Haskell * Supports binary numbers (sure, it's a trivial library issue, but possible because of type classes allow extending the concept of numbers) * The polymorphic equality is solved in Haskell, again, with type classes, allowing us to define equality to any user defined type in a way that makes sense for it (including the set example) * List concatenation is right associative (he mentions SML's left associative @ as a problem) * SML's overflow on + problem are solved by not having overflow (j/k, Haskell lack of overflow on integers is a serious problem IMO, but other than making Int === Integer there's no easy solution).
- scscsc 8y ago
  So you are agreeing with the author, since he is critiquing Standard ML (not Haskell). It is clear that the paper was influential, since Haskell does not have the shortcomings described.
  - FullyFunctional 8y ago
    Haskell predates the paper so no, I don't agree with your interpretation

grenadier21 8y ago

Partial evaluation of the viable strikes me as a very elegant idea! That way static dispatch just becomes a special case of virtual dispatch. It also reminds me of devirtualization optimization, and tangentially, how Rust does the opposite thing, by making boxed traits implement the traits, too, which makes dynamic dispatch a special case of static dispatch.

ernst_klim 8y ago

>In many ways O'Caml is a better SML than SML, but Haskell, and especially the GHC variant, has a type system that is light years ahead of both. Not true. Haskell does not have neither subtyping nor row and structural polymorphism for example.