[Haskell-cafe] Re: [Haskell] Top Level <-
ganesh at earth.li
Mon Sep 1 18:49:38 EDT 2008
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
> 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
> 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.
More information about the Haskell-Cafe