Type equality of monomorphic and polymorphic Char.char vectors exposed

[MatthewFluet]

MLton exposes the type equality of monomorphic and polymorphic Char.char vectors:

fun 'a id (x: 'a) : 'a = x

val _ : CharVector.vector -> Char.char Vector.vector = id
val _ : CharVectorSlice.slice -> Char.char VectorSlice.slice = id

For portability with other SML implementations, the type equality of monomorphic and polymorphic Char.char vectors should not be exposed.

[MatthewFluet]

Unlike the fixes for MLton/mlton#45 and MLton/mlton#47, which could be handled by some simply applications of opaque signature matching in the Basis Library implementation, hiding the type equality of monomorphic and polymorphic Char.char vectors is more difficult. This is because string constants must have the type CharVector.vector (equivalent to String.string) and the compiler elaborates string constants as Char.char vector.

Hiding these type equalities would be a more substantial refactoring of the treatment of constants in the compiler and Basis Library implementation. In particular, we might need to introduce a new form of overloading (e.g., _overload_const) to indicate the Basis Library (possibly opaque) types at which a constant could be elaborated.

[MatthewFluet]

An alternative approach might be to reuse the existing _overload extension and take a cue from Haskell's treatment of constants. That is, treat a string constant as an implicit application of the form:

  (_fromStringConst "string")

for an overloaded _fromStringConst function. (We choose a lexically invalid identifier to avoid conflicting with user code.) Any opaque type that should be denotable by a constant can simply provide an appropriate _fromStringConst identity function that will be added to the overload.