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