[MLton] extended basis library

[Stephen Weeks]

Here's a few thoughts and questions on the extended basis library.

Comment style
----------------------------------------
I saw a couple of commenting conventions that I liked.  I was 
wondering if they were aimed at automatic extraction of documentation,
and also if we should establish them as conventions.  The first style
was the "header" style.

  (** == ... == *)

Second was the convention of following specifications in signature
with the comment.

  val intIso : (char, Int.int) iso
  (**
   * The isomorphism between characters and character codes.  It
   * always equals {(ord, chr)}.  Note that the projection part of the
   * isomorphism, namely {chr}, is likely to be a partial function.
   *)

The MLton style has typically put the comment before the spec, which I
think is a mistake.

Formatting
----------------------------------------
The code is indented/layed-out in the MLton style, e.g.

  signature ISO =
     sig
        type ('a, 'b) iso = ...
        ...
     end

I'm not a fan of the style (despite having used it for so long) and
it's only inertia that keeps it in MLton.  I prefer the C-brace style

  signature ISO = sig
     type ('a, 'b) iso = ...
  end

  structure Iso:> ISO = sig
     ...
  end

  functor MkMonoVectorExt (M : MONO_VECTOR) = struct
     ...
  end

The advantage of this style is that it saves vertical space (no big
deal) and indentation nesting (a big win).

Naming convention for functors
----------------------------------------
I don't see the point of prefixing functors with "Mk".  It seems
redundant, as of course a functor is making a new structure.  Dropping
the "Mk" doesn't create a naming conflict, as functors have their own
namespace.  Also, there is no conflict in filenames as functors get a
different suffix (.fun).

Avoiding copying in MonoVector.{from,to}Poly
--------------------------------------------
One could almost use the following implementation of toPoly.

  fun toPoly v = 
    if MLton.isMLton then
       v
    else
       Vector.tabulate (length v, fn i => sub (v, i))

It doesn't quite work because MLton hides the equivalence between the
two types.  It would be worth exporting something in the MLton
structure to expose the equivalence so that one could avoid the copy.

One might worry that the use of the nonstandard "MLton.isMLton" makes
the code less portable.  But I don't think it's any worse than the use
of MLBs, Int64, etc..  In the end we will have to decide how much
effort we're willing to spend to implement code for other SML
compilers.  I'd like to do the best we can for MLton users, think of
the extended basis as a spec, and leave to other compilers to figure
out the best way to implement the spec in their compiler.

MLB convention
----------------------------------------
A useful convention in MLBs is to use an export filter to specify what
the MLB exports.  This is analogous to using a signature to specify
what a structure exports.  It nicely collects in one place all of the
exports, making it easier for a reader to understand at a glance.  It
is also easier than trying to carefully hide unwanted exports in a
number of "local"s.  Finally, it serves as a check that the code
really does export everything that you want.

For the extended basis, which also exports the basis library, I don't
think it's necessary to list all of the unchanged stuff. But listing
all the extended stuff would be nice, and not too wordy.  Perhaps the
following approach is the best way to capture what's going on.

  $(SML_LIB)/basis/basis.mlb
  local
    ...
  in
    signature EMB
    signature ISO
    signature INT_INF
    signature INTEGER
    signature REAL
    signature VECTOR
    signature ARRAY
    signature MONO_VECTOR
    signature MONO_ARRAY
    signature CHAR
    signature STRING
    signature TEXT
    structure Array
    structure BoolArray
    structure BoolVector
    structure Char
    structure CharArray
    structure CharVector
    structure Emb
    structure FixedInt
    structure Int
    structure Int1
    ...
    structure Int32
    structure Int64
    structure Int8Array
    structure Int8Vector
    structure Int16Array
    structure Int16Vector
    structure Int32Array
    structure Int32Vector
    structure Int64Array
    structure Int64Vector
    structure IntArray
    structure IntInf
    structure IntVector
    structure Iso
    structure LargeInt
    structure LargeIntArray
    structure LargeIntVector
    structure LargeReal
    structure LargeRealArray
    structure LargeRealVector
    structure LargeWord
    structure LargeWordArray
    structure LargeWordVector
    structure Position
    structure Real
    structure Real32
    structure Real32Array
    structure Real32Vector
    structure Real64
    structure Real64Array
    structure Real64Vector
    structure RealArray
    structure RealVector
    structure String
    structure SysWord
    structure Text
    structure Vector
    structure Word
    structure Word1
    ....
    structure Word32
    structure Word64
    structure Word8Array
    structure Word8Vector
    structure Word16Array
    structure Word16Vector
    structure Word32Array
    structure Word32Vector
    structure Word64Array
    structure Word64Vector
    structure WordArray
    structure WordVector
  end