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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
