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

Stephen Weeks MLton@mlton.org
Thu, 14 Jul 2005 12:08:18 -0700


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

Glad to hear it, Wesley.  Thanks for the compliments!

> 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 do wonder how much of reason for the difference between MLton and
OCaml/gcc is that we are so much smaller.  Hence, "outsiders" see a
larger fraction of developers' time; plus, there is less inertia from
others not to change.  I hope that one of our advantages is having an
open developer list (OCaml doesn't have one AFAIK) with a wide range
of contributors, a positive atmosphere, and a high signal-noise ratio.
I will continue to make efforts to keep it that way, but only time and
a lot of growth will tell how much better we can be than other
communities.  BTW, this list is certainly a place for discussion of
project organization and management approach, if anyone has ideas for
improvement.

> I only wish there was some sort of website where people could put
> their (even unfinished) SML programs up.

Well, there is mlton.org.  We have

  http://mlton.org/{Libraries,Users}

"Users" is even linked from the home page.  I suppose "Libraries"
could be as well, but it is only one extra click away via the
Documentation page.  And it is available in the index.  Anyways, I'm
open to other pages if those don't fit.

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

I think this comes back to having a packaging system.  Which, if I
ever get enough spare time, will be my top MLton priority.  Or, even
better, and certainly likely to yield results sooner, would be if
someone on this list would take up the charge.

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

Right.  We have no control over the basis library spec.  But MLBs plus
a reasonable packaging system (including a publicized site) means that
people can put stuff out there and whatever is good will get used,
regardless of whether it makes the official basis.  It would be nice
to keep the MLton structure (and compiler) as small as possible and
move stuff out into libraries (maintained by others).

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

I agree.  I think MLton is the right SML for serious application
development.  And as I've said before, I don't think we should go out
of our way to make it hard for other SML compilers or to deviate from
the standard.  But nor should we make our users' lives harder by
spending our time on portability or weakening our solutions to make
them portable.  It's the users that matter.