Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Critique of Standard ML (1992) [pdf]

cs.princeton.edu

Post reply on HN
Print view View original

11–14 of 14 posts

Re: A Critique of Standard ML (1992) [pdf]

#11

Post by ernst_klim »

FullyFunctional wrote: post #3

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 up…

>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.

Re: A Critique of Standard ML (1992) [pdf]

#12

Post by FullyFunctional »

scscsc wrote: post #8
FullyFunctional wrote: post #3

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 up…

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

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).

Re: A Critique of Standard ML (1992) [pdf]

#13

Post by scscsc »

FullyFunctional wrote: post #12
scscsc wrote: post #8

Earlier quoted context omitted.

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

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, solvin…

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.

Re: A Critique of Standard ML (1992) [pdf]

#14

Post by FullyFunctional »

scscsc wrote: post #13
FullyFunctional wrote: post #12

Earlier quoted context omitted.

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, solvin…

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.

Haskell predates the paper so no, I don't agree with your interpretation
Post reply on HN