You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike the fixes for #45 and #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.
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.
MLton exposes the type equality of monomorphic and polymorphic
Char.char
vectors:For portability with other SML implementations, the type equality of monomorphic and polymorphic
Char.char
vectors should not be exposed.The text was updated successfully, but these errors were encountered: