[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