Re: beginning with ML

Jon Harrop <usenet@xxxxxxxxxxxxxx> writes:


The only solution I can see is to wait until the INRIA team stop making
significant developments (which has arguably already happened) and then
persuade the distro package maintainers to ship a forked OCaml. In many
ways, that would be a great day. On the other hand, if Torben really can
build the foundation of a next generation technical computing platform in
only a few weeks maybe we should do that.

I said I could write a non-optimising compiler for core SML in a few
weeks, which is not quite the same. And it really says more about the
simplicity of core SML than it does about my abilities as a compiler
writer.

We should probably try to compile a list of features that we would all want
to see in a next generation ML.

Incidentally, what are people's feelings on type classes? Is ad-hoc
polymorphism enough?

I like Haskell type classes, though some of the experimental features
may be a little OTT (I would like the next generation ML to be
relatively simple). With type classes, the module system might be
simplified -- or you could integrate type classes and modules. I
think the latter requires some research, though.

There are lots of minor details regarding syntax etc. that I would
like in a future ML, but some of the more fundamental changes I would
like to see are:

- Concurrency.

- Linear types so you can, e.g., linearly type file handles to ensure
deterministic access order even in the presence of concurrency.

- A type-and-effect system so effects are visible in type but can be
delimited. Linearly typed file access can easily be delimited: It
only affects the file handle, which is consumed and a new one
produced, so you can treat the new file handle as a modified
"world".

Torben
.