[MLton-devel] new basis library

[Matthew Fluet]

> > I think that the opaque signature match on CharVector and String
> > means that we can use a type-constrained instance of the Vector
> > structure for CharVector;
> 
> I don't think so.  I see the following in the 02 spec:
> 
> structure CharVector :> MONO_VECTOR
>   where type vector = String.string
>   where type elem = Char.char
> 

There is also

structure String :> STRING 
  where type string = CharVector.vector
  where type char = char


Naively, I want to do the following:
type string = char vector (* in primitive.sml *)
functor MonoVector(type elem): MONO_VECTOR_EXTRA =
   struct
      open Vector
      type elem = elem
      type vector = elem vector
   end
structure CharVector = MonoVector(type elem = char)
structure String =
   struct
      open CharVector
      type char = elem (* = char *)
      type string = vector (* = char vector *)
      ... String operations ...
   end

signature BASIS = 
  sig
    ...
    structure CharVector: MONO_VECTOR
    sharing type elem = char
    structure String:> STRING
    sharing type string = CharVector.vector
    type string = String.string
  end

After opaque signature matching on MONO_VECTOR and STRING and exporting
String.string, it will be only equal to CharVector.vector and no longer
equal to char vector, even though we get to exploit that equality inside
the basis implementation.

> > but I don't know how that impacts the compiler's internal handling
> > of strings, string constants, and ffi.
> 
> strings and char vectors are different types, but have the same
> representation, so coercion between them is constant time (or even
> free if the backend/codegen do the right thing).

Is this essential?  Would it be very difficult to treat strings and
char vectors as equal types?



-------------------------------------------------------
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