[MLton] Extending the SML Basis library (Library project)

Vesa Karvonen vesa.karvonen at cs.helsinki.fi
Tue Oct 17 16:00:35 PDT 2006


Quoting Matthew Fluet <fluet at cs.cornell.edu>:
[...]
> I just don't find it intuitive to understand the meaning of:
> 
>    #1 Int32.int
> 
> Whereas, I find it easy to understand the meaning of:
> 
>    Int32.toInt

Just to clarify, the iso/emb values aren't meant to replace the to/from
functions.  So, one would (still) normally use the latter expression in
cases where one just wants to perform a single conversion.

> [...] I'm just worried that I would be throwing in Iso.swap blindly to get
> the types to work out. [...]
>
> > [...] When you supply an isomorphism to some function, you need to be
> > aware of the direction. [...]
> 
> Good point.  And, that's partly my concern, that using isomorphisms are 
> very context dependent, requiring more context than a reader is likely to 
> have internalized when looking at new code.

I think that your concern is quite valid (reading code making heavy use
of isomorphisms can be difficult until one understands enough of the context),
but I don't see any clearly superior way.  In particular, if we'd have each
function take in isomorphisms as context dependent records (e.g. records of
the form {toX, fromX} where X depends on context and possibly improves
readability locally) one would lose much of the ability to manipulate
isomorphism uniformly.

BTW, usually the first element (the injection function) of an isomorphism or
embedding is a mapping from some ad hoc (user-defined) type to some more
general type.  Of course, this doesn't always hold and isomorphisms don't
even necessarily have to be isomorphisms in the mathematical sense.

> There is no harm in having:
> 
>   signature ISO = sig
>     type ('a, 'b) t = ('a -> 'b) * ('b -> 'a)
>     ...
>     val make : ('a -> 'b) * ('b -> 'a) -> ('a, 'b) t
>   end
> 
>   structure Iso :> ISO
> 
> The opaque signature match is redundant, as the only type in the signature 
> has a transparent type definition; nonetheless, one has a 'home' structure 
> and a distinguished Iso.t type.

Yep.  I'll proceed with this one (concrete type + home structure).

-Vesa Karvonen



More information about the MLton mailing list