On Saturday 13 Nov 2004 9:15 am, Keean Schupke wrote: > >I'm not sure I understand what problem you think there is. Are the inits > >you're talking about module inits? If so, I don't think there's a problem, > >for several reasons. > > > >The idea under discussion is that a top level (x <- newThing) should > >be lazy, (no action at all occurs until value of x is demanded). IOW, > >it's exactly the same as the current unsafePerformIO hack, but not unsafe > >because the compiler knows the semantics. So there is no implied "module > >initialisation" > > Okay - I can see that with lazy semantics this might not be a problem... > What happens with > the second problem: That where module B uses A internally and C uses A > internally, then > I write a new module that tries to use B & C together... This > potentially breaks B & C. I think > you need the extra restriction that the top level '<-' bindings must not > be exported. So where > does that leave us. > > Top level inits are safe (I think) iff: > - They are lazy (the definition only happens when required) > - They contain only a subset of IO actions - namely those concerned > with name creation within Haskell that don't actually do any IO. > - They are not exportable from the module that contains them. > > I think that covers it... have I forgotten anything?
One of us has :-) Not sure who though. I thought I'd covered the second problem you're alluding to already. But if you think there's still a problem you'd better elaborate a little more. Certainly I see no reason why top level TWI's cannot be exported from a module. We don't have this constraint with the unsafePerformIO hack. For instance, if I had userInit <- oneShot realInit is there any reason why userInit can't be safely exported and used in many different modules? The whole idea was that it should be. Regards -- Adrian Hey _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
