On Mon, 1 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Well, the question of whether multiple copies of a module are ok is still
open, I guess - as you say later, it seems perfectly reasonable for two
different versions of Data.Unique to exist, each with their own types and
global variables - so why not two copies of the same version, as long as
the types aren't convertible? My feeling is that the the execution of <-
needs to follow the Data.Typeable instances - if the two types are the same
according to Data.Typeable, then there must only be one <- executed.
They will be different types if they are in different package versions.
Right, but they might be the same package version, if one is a dynamically
loaded bit of code and the other isn't.
Thus they could have different instances of Typeable. But why do we care
about Typeable?
Because of the coercion operation that follows from it.
So another question following on from that is what happens if there isn't
any datatype that is an essential part of the module - with Unique, it's
fine for there to be two <-s, as long as the Uniques aren't compared. Does
this kind of safety property apply elsewhere? It feels to me that this is
something ACIO (or whatever it would be called after being changed) needs
to explain.
In the internal implementation of Unique, there must be only one MVar
constructed with <- per Unique type, i.e. per package version. This will
work correctly, since values of Unique types from different package
versions have different types, and thus cannot be compared.
Unique values constructed at top level by <- will also be unique and will
work correctly.
My question was actually about what happens with some different library
that needs <-; how do we know whether having two <-s is safe or not?
I'd rather use Data.Typeable for this, and make sure (by whatever
mechanism, e.g. compiler-enforced, or just an implicit contract) that the
user doesn't break things with dodgy Typeable instances.
You don't think that's rather ugly: a class that needs special "deriving"
behaviour? I'd actually like to get rid of all special-case "deriving": it
should be for newtypes only.
No, it seems like the right way to do introspection to me, rather than
adding some new mechanism for describing a datatype as your paper
suggests.
Implicit contract is worse. I really shouldn't be able to write coerce
without referring to something marked "unsafe" or "foreign". Have we
stopped caring about soundness?
We could arrange for the class member of Typeable to be called
"unsafe...".
In addition, one can only have one Typeable instance per type. By
contrast, one can create multiple IOWitness values for the same type.
For example, one can very easily create a system of open exceptions for
IO, with an IOWitness value for each exception type, witnessing to the
data that the exception carries.
I don't see what the point of multiple values is, I'm afraid. A single
instance of Typeable is fine for doing type equality tests.
Cheers,
Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
