
An Anecdote About ML Type Inference (1994) - tjalfi
https://web.archive.org/web/20081006181650/http://www.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a
======
cannam
Just checked the code examples in a current Standard ML compiler, and they
work without modification and behave as described. That's why you should
choose Standard ML for your next project.

Great example though. When looking at Idris I had the impression there was a
logical end point of having the type system so descriptive that, given the
type of a function, there was only one possible implementation.

~~~
cmrdporcupine
About twenty years ago I endeavored to learn both Standard ML and OCaml, and I
found I preferred SML. I'm not clear how OCaml has gotten more mindshare, but
I really liked SML/NJ.

I suppose back then we were still in the throes of "object-oriented is best"
and the "object" in OCaml had some pull

~~~
agumonkey
I guess so. Both mainstream market mindshare and research freshness. The Ocaml
Object System was quite liked at the time for the solid backing.

------
dybber
Play with Standard ML in your browser:
[http://try.mosml.org/](http://try.mosml.org/)

There's also an SML compiler generating Javascript:
[http://www.smlserver.org/smltojs/](http://www.smlserver.org/smltojs/)

Just as a simple demo, I combined it with Processing, to make this little
thing: [http://hjemmesider.diku.dk/~dybber/processing-
sml/](http://hjemmesider.diku.dk/~dybber/processing-sml/)

------
perthmad
The phenomenon described in this article is actually an instance of Reynold's
parametricity. This one of the free stuff you get for using a (reasonable
version of) static typing.

------
Animats
This is a good argument for having argument types declared for functions and
structures, but inferring as much else as possible.

The trouble with inferring everything is someone reading the functions has no
idea what the restrictions are. The classic Python example involves "lists"
(built-in arrays) vs NumPy arrays. They implement most of the same operators
and functions, but with different semantics. For built-in arrays, "+" means
concatenate.

------
hellodanylo
I keep getting tricked by ML referring to either the programming language or
the subfield of AI.

~~~
shmageggy
It used to be that "type inference" would successfully disambiguate, but now
things like these exist
[https://arxiv.org/abs/2005.02161](https://arxiv.org/abs/2005.02161)
[https://arxiv.org/abs/2004.10657](https://arxiv.org/abs/2004.10657)

------
fizixer
\- SML is old

\- OCaML has OO cruft and OCaML folks themselves keep telling you "Oh, you
don't have to use the OO parts of OCaML"

Well then effin give me an ML that's more modern than SML, and has no OO
cruft!

don't tell me "take this stuff that we think is good, and just ignore parts of
it that are bad"

(and I'm not interested in Haskell).

edit: Matt Might lists only two other languages [0], Scala and Scheme. Both
are not ML (though I think some folks think Scala is an ML?)

[0] [http://matt.might.net/articles/best-programming-
languages/](http://matt.might.net/articles/best-programming-languages/)

~~~
dybber
What is the problem with being old? I see the main problem with SML as lack of
libraries and community.

~~~
fizixer
I guess SML would be it then. I'm sick and tired of the OCaML community that
tells you to use OCaML, as if it's better than SML, but then tells you not to
worry about the OO parts.

