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