[Haskell-cafe] Re: [Haskell] Top Level <-
ganesh at earth.li
Tue Sep 2 01:00:48 EDT 2008
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
>> 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
> 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
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.
More information about the Haskell-Cafe