[MLton] MLton rules! (was: filedes = int)

[Wesley W. Terpstra]

On Mon, Jul 11, 2005 at 01:49:34PM -0700, Stephen Weeks wrote:
> 
> > Now that there is a complete front-end, we could achieve the same by
> > 
> > -	datatype file_desc = FD of int
> > +	structure FD :> sig type t end = struct type file_desc = int end
> > +	type file_desc = FD.t
> 
> I like this solution, and it is used in other places in the basis
> library.  I'm tempted to make the change.

Indeed, I see that you already have!

I just need to express how happy I am that I am a MLton user:

When I looked at ML, I thought that it was a very pretty language that
had the sorts of features I would enjoy using. Then I saw benchmarks that
showed that the nice abstractions still compiled to good executables.
Nevertheless, Iīve had past experience where toy languages that look nice
donīt work out when used for practical problems, so I remained sceptical.

Naturally, since it is bigger, I tried OCaml first. However, since ML is 
an immature language (in terms of features needed for actual work as an
application developer), I needed things that werenīt available. So, I
pointed out their lack and asked what else could do the trick.

All the OCaml community offered was the email equivalent of a blank stare.
Then I dropped OCaml and tried MLton.

What makes MLton so great isnīt just the excellent compiler, but you guys!
Whenever thereīs something that doesnīt fit, you guys not only reply
promptly and discuss the issue, but are willing to change things if they
need changing. I think that if more people were aware of how quickly MLton
evolves and resolves problems, they would be more willing to invest effort
into learning it. Iīve had the same problems with gcc/libc---the people who
maintain it are too rigid and apathetic towards suggestions from outside of
their inner circles.

I only wish there was some sort of website where people could put their
(even unfinished) SML programs up. The more code there is that is visible,
the larger the apparent community of SML programmers, and the more
programmers will be willing to take the leap and learn SML. Including
features as MLton extensions is nice, but it reduces the visibility of 
how much stuff there actually is for SML.

Iīm sure most of us have a fairly large body of code which we havenīt
published anywhere online, simply because thereīs nowhere easy to put it.
Even I already have two fairly useful libraries. This collection of shared
code doesnīt need to be the same calibre as boost, but when you need a 
solution, even something is better than nothing, and itīs publicity.

Finally, my biggest problem with SML is the same complaint I had about
OCaml: rigidity and scope. Here I am talking about the basis library.
I have pretty much given up on seeing changes (like Unicode or Vesa
Karvonenīs infix operators) ever reaching the basis library. If there
was some sort of collection of code where things could be discussed and
stabilized, I think this point would become less important.

In my opinion, it would be best if this collection of code was affiliated
with MLton. Although there are other SML compilers (forgive me if I step 
on someoneīs toes here), I donīt think any of them really address the needs
of an application developer as well as MLton does. By specializing for one
compiler, you get a more cohesive community: look at gcc!

-- 
Wesley W. Terpstra