This was my point, I may _want_ two copies of the library. Lets say I want to
write a virtual machine emulator in haskell, and I then wish to use your
library to drive the virtualised hardware... There must be some way to
encapsulate the state requirement of the library such that the VM software
can manage multiple states. At the momemt (with the handle approach)
this is entirely possible:
a <- initLibrary b <- initLibrary
With you suggestion this VM cannot be written in Haskell any more. This is the point that I object to (and have been trying to explain badly).
Perhaps the following extension would fix things:
main = do
a <- import Library -- a would be a record containing top level of library
b <- import Library
Keean.
Adrian Hey wrote:
On Wednesday 24 Nov 2004 9:37 pm, John Meacham wrote:
On Wed, Nov 24, 2004 at 03:48:56PM +0000, Keean Schupke wrote:
Having admited to wavering on the edge of accepting top level TWIs, perhaps one of the supporters would like to comment on qualified importing... IE what happens to the unique property if I import 2 copies like so:
module Main where
import Library as L1 import Library as L2
Although each library's internal state is initialised once, as required,
any real
IO could lead to problems... With the device driver example I now have
two bits of code that think they have exclusive access to the device...
But I can do:
Hmm? I am not really sure what you are asking. With my mdo proposal, and I think all proposals brought forth, the module system behaves identically to how it normally does for namespace control. top level initializers are just constant definitions for all most everything is concerned.
modules do not change code at all, they are pure syntantic sugar for deciding what names you can see.
i.e. it does not matter whether you do
import List as L1 import List as L2
L1.sort and L2.sort refer to the same thing. it would be no different if
sort were written with global state or even was a top level binding.
I think Keean is assuming the idea is that one should be able to duplicate top level TWIs by importing the same module twice. But of course this is not what's wanted. For example, it would enable users to short circuit the safety provisons of all the "oneShot" examples.
If the purpose of a module is to allow users to have multiple distinct (top level or otherwise) TWIs then it should be exporting an appropriate newTWI constructor which is used in the usual manner by the importing module(s)..
myTWI <- newTWI myOtherTWI <- newTWI
Regards -- Adrian Hey
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
