[MLton-devel] new basis library

Stephen Weeks MLton@mlton.org
Wed, 24 Jul 2002 19:15:19 -0700


> Note, I really like the idea of the opaque signatures, even if they'll be 
> tough to get right. For example, MLton currently accepts the following
> program:
> 
> val v = Vector.fromList [false, true, false]
> val b = BoolVector.foldr (fn (a,b) => a andalso b) true v
> val _ = print (Bool.toString b);
> 
> But, if we ever implemented BoolVector.vector as a bit-vector, then the
> program would fail to type-check.

Not necessarily.  We might also implement "bool vector" as a
bit-vector at the same time.

> Under the new basis, the program fails to type check regardless of the
> implementation of BoolVector.vector.

I agree this is a good thing.


Maybe the right way to solve our problems is by writing a single
signature describing everything in the basis library (except
signatures) and expresses exactly the sharing constraints we want.
Something like

signature BASIS =
   sig
      datatype bool = false | true
      val not: bool -> bool
      structure Bool: BOOL
      sharing type Bool.bool = bool
      structure BoolVector: MONO_VECTOR 
      sharing type BoolVector.elem = Bool.bool
      structure BoolVectorSlice: MONO_VECTOR_SLICE 
      sharing type BoolVectorSlice.vector = BoolVector.vector
      sharing type BoolVectorSlice.elem = bool
      structure BoolArray: MONO_ARRAY 
      sharing type BoolArray.vector = BoolVector.vector
      sharing type BoolArray.elem = bool
      structure BoolArraySlice: MONO_ARRAY_SLICE 
      sharing type BoolArraySlice.vector = BoolVector.vector
      sharing type BoolArraySlice.vector_slice = BoolVectorSlice.slice
      sharing type BoolArraySlice.array = BoolArray.array
      sharing type BoolArraySlice.elem = bool
      structure BoolArray2: MONO_ARRAY2 
      sharing type BoolArray2.vector = BoolVector.vector
   end

Then, we can define all the modules within the basis library as we do
now, and take advantage of type sharing.  And, instead of the
structure definitions in top-level.sml, we do the following.

local
   structure Basis:> BASIS =
      struct
	 datatype bool = datatype bool
	 structure Bool = Bool
         ...
	 open BoolGlobal
         ...
      end
in
   open Basis
end

Does this give us what we want?  Does it make it easy to read the
basis library spec as code for a signature (using sharing instead of
where)?  It seems nice to me because it is a single opaque match and
is therefore easy to reason about.  Maybe the basis library spec
should even include the BASIS signature.


-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel