[Haskell-cafe] Re: [Haskell] Top Level <-

[Ganesh Sittampalam]

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