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

[Ashley Yakeley]

Ganesh Sittampalam wrote:
> 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.

Already the dynamic loader must load the module into the same address 
space and GC, i.e. the same runtime. So it should be able to make sure 
only one copy gets loaded.

What is the status of dynamic loading in Haskell? What does hs-plugins 
do currently?

> Well, the safety of <- being run twice in the Data.Unique case is based 
> around the two different Data.Unique types not being compatible.

Right. The only code that can construct Unique values is internal to 
Data.Unique.

> 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?

In this case, duplicate modules of different versions is as safe as 
different modules. In other words, this situation:

   mypackage-1.0 that uses <-
   mypackage-2.0 that uses <-

is just as safe as this situation:

   mypackage-1.0 that uses <-
   otherpackage-1.0 that uses <-

The multiple versions issue doesn't add any problems.

> 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 <-.

Why don't you like <-? Surely I've addressed all the issues you raise? 
Multiple package versions does not actually cause any problems. 
Capabilities would be really nice, but the right approach for that is to 
create a new execution monad. There is an obligation regarding dynamic 
loading, but it looks like dynamic loading might need work anyway.

Since this is a matter of aesthetics, I imagine it will end with a list 
of pros and cons.

> 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. 

It's worse than that. If you derive an instance of Typeable for your 
type, it means everyone else can peer into your constructor functions 
and other internals. Sure, it's not unsafe, but it sure is ugly.

>> 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.

It's not what newtype is designed for. Newtype is designed to create 
usefully new types. Here, we're only creating different dummy types so 
that we can have different TypeRep values, which act as witnesses. It's 
the TypeReps that actually do the work.

It would be much cleaner to declare the witnesses directly.

-- 
Ashley Yakeley