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

[Ashley Yakeley]

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?

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

> 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? It 
looks like an ugly hack to me. We have a class with a member that may be 
  safely exposed to call, but not safely exposed to define. How is this 
the right way?

By contrast, top-level <- is straightforward to understand. Even the 
scope issues are not hard. It's safe, it doesn't privilege a class with 
special and hidden functionality, it doesn't introspect into types, and 
it allows individual unique values rather than just unique instances per 
type. And it also allows top-level IORefs and MVars.

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

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

Or if I want, I can create a dictionary of heterogeneous items, with 
IOWitness values as keys. Then I can do a top-level <- to declare keys 
in this dictionary. Now I've got OOP objects.

-- 
Ashley Yakeley