[Haskell-cafe] Re: [Haskell] ANN: IOSpec 0.1
Hi Twan, Wouter Swierstra wrote: Test.IOSpecVersion 1.0 Shouldn't that be 0.1? You're right of course. You use Dynamic for the data type in IORefs, this has the unfortunate consequence of needing Typeable constraints. You could try to use unsafeCoerce instead, type Data = () unsafeToData :: a - Data unsafeToData = unsafeCoerce unsafeFromData :: Data - a unsafeFromData = unsafeCoerce I think this should be just as safe as Dynamic, since internally Dynamic uses unsafeCoerce as well. Just steal the details from there. I'm not entirely happy with the unsafeFromDynamic approach I use at the moment. GHC can derive instances of Typeable, so the price you have to pay is not too high. The real problem is that Haskell's type system is not expressive enough to cleanly describe the type of the heap (I know, I could be using HList, but still...). If you're interested, I also have a dependently typed version of the code for IORefs that allows heterogeneous, type-safe, well-scoped pointers. I should probably mention that an ulterior motive for this work is integrating IO in dependently typed languages such as Epigram. It is all, of course, still very much subject to active research. Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: IOSpec 0.1
Hi Isaac, Moving to Haskell-cafe How does or might this relate to the typeclass-based Restricted IO monad http://article.gmane.org/gmane.comp.lang.haskell.general/14526 ? RIO's technique has the advantage that multiple capabilities can be easily combined in one use of the monad - but this manner of using typeclasses might interfere with how testable it is? (I think that should be okay... Also that this is a really neat project - incremental progress on taming Haskell IO in practice!) Stefan is absolutely right. The RIO, as far as I remember, restricts which parts of the IO monad you use. The same could be said for the Test.IOSpec modules. However, the Test.IOSpec also give you a pure specification of the functions you are using. This is very important if you want to trace/debug an execution of you code - you can see how the state of your machine changes at every step. There's also a bit finer control over how you test your functions: concurrent code is parameterised over the scheduler, for instance. Both these aren't possible with the RIO approach. P.S. why *If you're an ICFP referee, you may want to avoid reading any further* ICFP has a double-blind review process: if I were to submit a paper, I should do so anonymously. The idea behind it all is that if the reviewers don't know who the author of a paper is, they can't be prejudiced. The code I just released is described in a paper submitted to ICFP. All the best, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: IOSpec 0.1
Hi Stefan, in the Teletype module, it would probably be better to reflect IOTeletype operations as: data Action a = Finish a | Put Char (Action a) | Get (Char - Action a) That way, there is no need to use (unobservable) laziness. I'm afraid I've lost you. How does this differ from the current definition of IOTeletype? Thanks, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
