hello stefan > that was exactly what i was about to do ... what was > the problem with this approach?
it is some time ago, however i imagine the problem was that connecting a (P s1 a) graph with a (P s2 a) graph is a nuisance. the simplicity of being able to connect any (P a) to any other (P a) is part of the 'charm' of the system... > i would think that if step were exposed in the > interface, i could pass in a new state for each value > produced by the pattern; a hypothetic `pask' would > return the current state (or rather environment; it's > not changed by the patterns). i think i concluded that what'd be best is to extend the internal state from simply StdGen to perhaps something like: data PState = PState StdGen Control.Concurrent.Chan and provide some way for users to access the channel. this'd allow external asnchronous communication but require it to go through a common representation, maintaining the simple and interconnectable (P a) type signature. > what do you mean by plain haskell, lazy lists? i'm > having trouble imagining how i could deal with > asynchronous events, but that's probably just my lack > of imagination ;) actually Control.Concurrent.Chan.getChanContents works suprisingly well! but no, i just meant using the standard Control.Concurrent libraries and writing for the 'specific case' - ie. no 'frameworks'! > i think the patterns could be regarded as a kind of > poor man's FRP, where reactivity is limited to the > reoccurring "timer event" from the step > invocations. i like their simplicity in comparison > with the currently available "real" FRP systems, > apart from the fact that my experiments with reactive > in particular have been basically fruitless ... yes, i more or less agree, and it'd be nice to have a shared 'framework' for these 'minimal pattern like behaviours'. however i'm not sure i have a good enough solution to try and convince other people to use it! i guess it'd need to somehow support at least the most useful of the various 'merging' rules, also blocking and non-blocking external reads (ie. pause pattern until data available, or provide cached data) etc. as mentioned before, i'd very happily take patches and help out if i can! > maybe the (planned?) new version of haskore comes to > the rescue? http://lambda-the-ultimate.org/node/3659 looks promising, but these systems often 'look promising'! bests rohan _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
