[Haskell-cafe] Re: [Haskell] Top Level <-
ashley at semantic.org
Mon Sep 1 18:38:28 EDT 2008
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.
Thus they could have different instances of Typeable. But why do we care
> 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.
ua <- newUnique
ub <- newUnique
Here ua == ub will evaluate to False.
> 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.
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?
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.
More information about the Haskell-Cafe