A Critique of Standard ML (1992) [pdf]
cs.princeton.edu
A Critique of Standard ML (1992) [pdf]
1–10 of 14 posts
Re: A Critique of Standard ML (1992) [pdf]
#2The Author is Andrew Appel, who wrote "Compiling with Continuations" (92). He's still publishing: http://www.cs.princeton.edu/~appel/papers/
Re: A Critique of Standard ML (1992) [pdf]
#3I 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
Re: A Critique of Standard ML (1992) [pdf]
#4I 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 up…
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.
Re: A Critique of Standard ML (1992) [pdf]
#5The Author is Andrew Appel, who wrote "Compiling with Continuations" (92). He's still publishing: http://www.cs.princeton.edu/~appel/papers/
I just found this in one of those papers (http://www.cs.princeton.edu/~appel/papers/wand-frame.pdf). In the text:
> Magic wands are famously difficult to control [15]....
In the references:
15. J. K. Rowling. Harry Potter and the Philosopher’s Stone. Bloomsbury Childrens, London, 1997.
Re: A Critique of Standard ML (1992) [pdf]
#6Not much of expert here, but have played with ML. I find interesting that he criticizes "Restrictive type system". However, also at the same time likes the "Compile-time
type checking".
I definitely did not read the entire paper in detail considering it's length. However, he brings up ML's type system a lot. I thought that was one ML's main advantages. Although, at the same time criticizing some of the decisions or results from those decisions.
Re: A Critique of Standard ML (1992) [pdf]
#7Not much of expert here, but have played with ML. I find interesting that he criticizes "Restrictive type system". However, also at the same time likes the "Compile-time type checking". I definitely did not read the entire paper in detail considering it's length. However, he brings up ML's type system a lot. I thought that was one ML's main advantages. Although, at the same time criticizing some of the decisions or r…
> I find interesting that he criticizes "Restrictive type system".
He doesn't? He quotes an anonymous reviewer and points out that the type system is not very restrictive and well worth it.
Re: A Critique of Standard ML (1992) [pdf]
#8I 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 up…
What are the "many" other issues (other than the two you mentioned in your comments)?
Re: A Critique of Standard ML (1992) [pdf]
#9I 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 up…
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.
Re: A Critique of Standard ML (1992) [pdf]
#10[deleted]