hi rohan, Rohan Drape wrote: >> 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...
hmm, yes, that might turn out to be a problem, but i'll have to experiment a little first. in a particular use case i have there's only ever going to be pattern graphs of the same type, so i'll try how far i get. >> 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. but you still would need to expose the type of the channel elements in P, wouldn't you? also, patterns then wouldn't represent pure computations anymore. >> 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 see what you mean; my goal atm is to have some kind of DSL that can be taught to non-programmers, and based on my experiences with the SC pattern system, i wanted to give yours a try. > 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. yes, in my view this is one of the major shortcomings of the SC pattern system: events are not first class, but are so to speak implicitly present by injecting them into a pattern graph by an impure driver function, yielding one event per input event. for blocking reads for example, it's possible to write a new driver function, but running pattern graphs (on different drivers) cannot easily communicate and exchange events. it woud be interesting to hear the opinion (or even success stories) of others on this list, because i know some have been very active in FRP research ;) > http://lambda-the-ultimate.org/node/3659 looks > promising, but these systems often 'look promising'! interesting read indeed, thanks for the pointer! <sk> _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
