[MLton] extended basis library

[Stephen Weeks]

> OTOH, I also dislike the exception to omit indentation when a
> top-level module declaration is in its own file.  So, perhaps the
> C-brace style is a practical compromise.

That's what I've concluded.

> At any rate, I don't think that we should mandate any specific
> indentation style, but strongly recommend using using some
> consistent style within a library.

Agreed.

> In the long run, we should have a documentation extractor which
> means that library users don't necessarily have to browse the source
> code.

I'm looking forward to it.

I've also been getting inspired to write an indentor.

> Is there some reason why the equivalences between polymorphic and
> monomorphic vectors (and likewise for arrays) aren't exposed?  I
> haven't noticed anything in the basis library manual that would
> disallow it.

I don't think it is clearly stated anywhere.  The idea is that if the
spec doesn't say that two types are equivalent, then they shouldn't
be.

> I would guess that the main reason to not expose the equivalences is
> to avoid exposing an implementation detail that might change.

Right.  It might change from one version of an implementation to
another, and certainly changes between different SML implementations.
Of course, MLton doesn't hide the equivalences for integral and word
types because there are some drawbacks to doing so.

> it would nice if, in addition to -show-basis, MLton would have an
> option, say -show-basis-summary, that would only show the kinds
> (type, val, signature, structure, ...) and names of all exported
> top-level bindings

Makes sense.

> It might also be useful to show the infix status of identifiers in
> -show-basis output.

Also makes sense.