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

[Ganesh Sittampalam]

On Mon, 1 Sep 2008, Ashley Yakeley wrote:

> Ganesh Sittampalam wrote:
>> Right, but they might be the same package version, if one is a dynamically 
>> loaded bit of code and the other isn't.
>
> OK. It's up to the dynamic loader to deal with this, and make sure that 
> initialisers are not run more than once when it loads the package into the 
> RTS. The scopes and names are all well-defined. How hard is this?

I have a feeling it might be non-trivial; the dynamically loaded bit of 
code will need a separate copy of the module in question, since it might 
be loaded into something where the module is not already present. So it'll 
have a separate copy of the global variable in a separate location, and 
the dynamic loader needs to arrange to do something weird, like copying 
the value of the first run <- to the second one instead of running it 
again.

>
>> 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 don't understand. When is it not safe?

Well, the safety of <- being run twice in the Data.Unique case is based 
around the two different Data.Unique types not being compatible. Let's 
suppose some other module uses a <-, but returns things based on that 
<- that are some standard type, rather than a type it defines itself. Is 
module duplication still safe?

>> 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.
>
> Aesthetic arguments are always difficult. The best I can say is, why are 
> some classes blessed with a special language-specified behaviour?

Well, let me put it this way; since I don't like <-, and I don't 
particularly mind Typeable, I wouldn't accept IOWitness as an example of 
something that requires <- to implement correctly, because I don't see any 
compelling feature that you can only implement with <-.

>> We could arrange for the class member of Typeable to be called "unsafe...".
>
> We could, but it's not actually unsafe to call as such. It's only unsafe to 
> implement.

That's fine, it can export a non-class member without the unsafe prefix.

> And if we're going the implicit contract route, we have to resort to 
> unsafe functions to do type representation. It's not necessary, and 
> seems rather against the spirit of Haskell.
>
> Time was when people would insist that unsafePerformIO wasn't Haskell, 
> though perhaps useful for debugging. Now we have all these little unsafe 
> things because people think they're necessary, and there's an implicit 
> contract forced on the user not to be unsafe. But it turns out that 
> they're not necessary.

There's some unsafety somewhere in both Typeable and IOWitnesses, and in 
both cases it can be completely hidden from the user - with Typeable, just 
don't let the user define the typeOf function at all themselves. I'm not 
actually sure why it is exposed; is it necessary for some use pattern?
>
>> 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.
>
> Sometimes you want to do witness equality tests rather than type equality 
> tests. For instance, I might have a "foo" exception and a "bar" exception, 
> both of which carry an Int. Rather than create new Foo and Bar types, I can 
> just create a new witness for each.

This is precisely what newtype is designed for, IMO. We don't need another 
mechanism to handle it.

Cheers,

Ganesh