On Sun, 31 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
That sounds more feasible - though it does constrain a plugin architecture (in which Haskell code can dynamically load other Haskell code) to cooperate with the loading RTS and not load multiple copies of modules; this might make linking tricky.
This is a good idea anyway. It's up to the dynamic loading architecture to get this right.
Well, the question of whether multiple copies of a module are ok is still open, I guess - as you say later, it seems perfectly reasonable for two different versions of Data.Unique to exist, each with their own types and global variables - so why not two copies of the same version, as long as the types aren't convertible? My feeling is that the the execution of <- needs to follow the Data.Typeable instances - if the two types are the same according to Data.Typeable, then there must only be one <- executed. So another question following on from that is what happens if there isn't any datatype that is an essential part of the module - with Unique, it's fine for there to be two <-s, as long as the Uniques aren't compared. Does this kind of safety property apply elsewhere? It feels to me that this is something ACIO (or whatever it would be called after being changed) needs to explain.
What applications does this leave beyond Data.Unique and Random?
So far we've just looked at declaring top-level IORefs and MVars.
By declaring top-level values of type IOWitness, you can generate open witnesses to any type, and thus solve the expression problem. See my open witness library and paper: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/open-witness http://semantic.org/stuff/Open-Witnesses.pdf
I'd rather use Data.Typeable for this, and make sure (by whatever mechanism, e.g. compiler-enforced, or just an implicit contract) that the user doesn't break things with dodgy Typeable instances. Cheers, Ganesh