It seems to be a trend to use more and more IO in new FRP approaches. Grapefruit's circuits encapsulate side effects, as does your approach
This is a big departure from the "pure" libs like Fran, Yampa, Reactive, ... I wander if this is because of some fundamental problem with functional programming when it comes to FRP? Some people claim that IO is also pure, and I tend to agree if we can capture the state of the real world and rewind to it somehow :) On Thu, Apr 2, 2009 at 4:06 PM, Jeff Heard <[email protected]>wrote: > Check links... god. http://vis.renci.org/jeff/buster (can you tell > I was up till 3am last night?) > > On Thu, Apr 2, 2009 at 10:05 AM, Jeff Heard <[email protected]> > wrote: > > Yes,sorry. vis, not vs. http://vis.renci.org/buster > > > > It is a bit like grapefruit's circuits, but where Grapefruit circuits > > describe the flow of events from place to place, Buster never does. > > Events exist for all behaviours, to be selected by name, group, or > > source. The other major difference is the |~| or "beside" operator, > > which describes concurrent application of behaviours. > > > > A last but somewhat minor thing is that the Event type is fairly > > general, allowing for multiple data to be attached to a single event > > and this data to be of many of the standard types (Int, String, > > Double, ByteString, etc) as well as a user-defined type. Of course, > > such an event type could be defined for other FRP frameworks as well. > > > > -- Jeff > > > > On Thu, Apr 2, 2009 at 9:53 AM, minh thu <[email protected]> wrote: > >> It's vis instead of vs: > >> http://vis.renci.org/jeff/buster/ > >> > >> 2009/4/2 Peter Verswyvelen <[email protected]>: > >>> Sounds vaguely like Grapefruit's circuits, but I could be very wrong... > >>> The link you provided seems to be broken? > >>> On Thu, Apr 2, 2009 at 3:05 PM, Jeff Heard < > [email protected]> > >>> wrote: > >>>> > >>>> Read more about it on its webpage: http://vs.renci.org/jeff/buster > >>>> > >>>> Yes, it’s to solve a particular problem. And yes, this is a rough > >>>> draft of an explanation of how it works. I’ve not even really > >>>> solidified the vocabulary yet, but I have this module which couches a > >>>> large, abstract, interactive (both with the user and the system), > >>>> multicomponent application in terms of a bus, inputs, behaviours, and > >>>> events. > >>>> > >>>> * Time is continuous and infinite. > >>>> * An event is a static, discrete item associated with a particular > >>>> time. > >>>> * The bus is the discrete view of event in time at an instant. > >>>> * A widget is an IO action that assigns events to a particular > >>>> time based only upon sampling the outside world (other events and > >>>> behaviours are irrelevant to it). e.g. a Gtk Button is a widget, a > >>>> readable network socket is an widget, the mouse is an widget, the > >>>> keyboard is an widget, a multitouch gesture engine is a widget. > >>>> * A behaviour is a continuous item — it exists for the entire > >>>> program and for all times — which maps events on the bus to other > >>>> events on the bus. It is an IO action as well — where widgets only > >>>> sample the outside world and are in a sense read only, behaviours > >>>> encapsulate reading and writing. > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> [email protected] > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> [email protected] > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >>> > >> > > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
