Ryan Ingram wrote:
Heinrich Apfelmus wrote:
However, even in a demand-driven implementation, there is one optimization
that I would like make: when there are multiple external events, say e1 and
e2, the network splits into subnetworks that react only to one of the
inputs. For instance, your
On Tue, Apr 26, 2011 at 11:44 PM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
However, even in a demand-driven implementation, there is one optimization
that I would like make: when there are multiple external events, say e1 and
e2, the network splits into subnetworks that react only
Ryan Ingram wrote:
Apfelmus, I hope you don't abandon your efforts, at least for the selfish
reason that I enjoy reading your blog entries about trying to implement it!
:D My reasoning was that a temporary demand-driven implementation would
allow me to release the library sooner; I want
Edward Amsden wrote:
As far as I can tell, with classic FRP implementations (those which
use behaviors as a first-class abstraction), the only way to create a
behavior or
event based on some external input (for instance keypresses or
microphone input) is to do something with unsafePerformIO or
Apfelmus, I hope you don't abandon your efforts, at least for the selfish
reason that I enjoy reading your blog entries about trying to implement it!
I was looking at your last entry and trying to understand if/how you solve
the order-dependency problem for events. In particular:
source events
As far as I can tell, with classic FRP implementations (those which
use behaviors as a first-class abstraction), the only way to create a
behavior or
event based on some external input (for instance keypresses or
microphone input) is to do something with unsafePerformIO or
unsafeInterleaveIO. A
Of course, you could have the 'interpretation' function be non-pure.
For example:
-- Library functions for a hypothetical FRP system
pollEvent :: IO [a] - Event a
behavior :: a - Event a - Behavior a
accumB :: b - (b - a - b) - Event a - Behavior b
accumE :: b - (b - a - b) - Event a - Event b
Mail fail, haha. Code fixed.
For example:
-- Library functions for a hypothetical FRP system
pollEvent :: IO [a] - Event a
behavior :: a - Event a - Behavior a
accumB :: b - (b - a - b) - Event a - Behavior b
accumE :: b - (b - a - b) - Event a - Event b
union :: Event a - Event a - Event a
