Re: [Haskell-cafe] Informal modelling and simulation of protocols

Is there some fantastic tool/library which already does everything I want?
Have you looked into model checkers like Spin, which was developed for the very purpose of exhaustively checking protocols? See spinroot.com Doug McIlroy

http://hackage.haskell.org/package/dejafu might do what you want
On Mar 4, 2019, at 10:33 PM, Doug McIlroy
wrote: Is there some fantastic tool/library which already does everything I want?
Have you looked into model checkers like Spin, which was developed for the very purpose of exhaustively checking protocols? See spinroot.com
Doug McIlroy _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Hi, Will (and Ian)
On Tue, 5 Mar 2019 at 23:11, Will Yager
http://hackage.haskell.org/package/dejafu might do what you want
From a quick look at the documentation... am I right in thinking that
Thanks for the suggestion, that does look useful. this test framework only covers concurrency when you're directly using IOVars and STM? Any concurrency that might involve other primitives, or IOVar/STM uses in libraries, wouldn't be testable? Unless the primitives/library had also been written to use the dejafu io classes and monads of course... which might be a good idea in and of itself. Definitely looks good for helping ensure correctness at my protocol implementation layer, and I can conceive of building a protocol model testable by it, so thanks for the link. Need to think more about the relative merits of that approach vs Spin vs FRP. Thanks.

Quoting P Orrifolius (2019-03-10 20:38:05)
On Tue, 5 Mar 2019 at 23:11, Will Yager
wrote: http://hackage.haskell.org/package/dejafu might do what you want
Thanks for the suggestion, that does look useful. From a quick look at the documentation... am I right in thinking that this test framework only covers concurrency when you're directly using IOVars and STM? Any concurrency that might involve other primitives, or IOVar/STM uses in libraries, wouldn't be testable? Unless the primitives/library had also been written to use the dejafu io classes and monads of course... which might be a good idea in and of itself.
Yeah, if you have dependencies not written in terms of those type classes, it may be difficult to integrate. If it's just your own code, it shouldn't be too hard to go through and swap in the type class constraints everywhere, but I do wish Haskell made it easier to wedge an abstraction layer like that under existing libraries after the fact :(. -Ian

Hi,
On Tue, 5 Mar 2019 at 23:11, Will Yager
wrote: http://hackage.haskell.org/package/dejafu might do what you want
Thanks for the suggestion, that does look useful. From a quick look at the documentation... am I right in thinking that this test framework only covers concurrency when you're directly using IOVars and STM? Any concurrency that might involve other primitives, or IOVar/STM uses in libraries, wouldn't be testable? Unless the primitives/library had also been written to use the dejafu io classes and monads of course... which might be a good idea in and of itself.
Yes, that's the case. It's a bit of an unfortunate limitation but I don't currently have a way around it. You may find it interesting to look at adjoint.io's libraft, which uses dejafu for some tests: https://github.com/adjoint-io/raft/blob/master/test/TestDejaFu.hs The way they do it is by writing their library in terms of some "MonadRaft" classes, and give a concrete implementation of those classes in terms of dejafu's ConcIO monad for testing. -- Michael Walker (http://www.barrucadu.co.uk)

On Tue, 5 Mar 2019 at 03:33, Doug McIlroy
Is there some fantastic tool/library which already does everything I want?
Have you looked into model checkers like Spin, which was developed for the very purpose of exhaustively checking protocols? See spinroot.com
Thanks for lead. Spin does seem to be an appropriate tool for the job. I was/am sort of hoping the protocol modelling and implementation would both be in Haskell to get some reuse, but the consensus seems to be that Spin's modelling language is pretty easy to use so maybe it would be no extra work overall. I'm sure I've still got the implementation and protocol itself somewhat confused, so what state is truly required for the protocol is a bit muddled. Not certain how I would represent it in spin, just need to play around with it I guess. That's partly what I was getting at with my 'modelling operators over domains' ramble... trying to avoid increasing the state space by enumerating through all data type values without abstracting the protocol model by just checking boundary cases. Or at least abstracting in a disciplined way that makes me confident all boundary cases are checked, not just those I happened to think of and model. But perhaps Spin already has some state space compression tricks of that nature and I'm worrying over nothing. Anyway, thanks for the pointer!
participants (5)
-
Doug McIlroy
-
Ian Denhardt
-
Michael Walker
-
P Orrifolius
-
Will Yager