[Haskell-cafe] ANN: Buster 0.99.1, a library for application orchestration that is not FRP

[Peter Verswyvelen]

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 <jefferson.r.heard at gmail.com>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 <jefferson.r.heard at gmail.com>
> 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 <noteed at gmail.com> wrote:
> >> It's vis instead of vs:
> >> http://vis.renci.org/jeff/buster/
> >>
> >> 2009/4/2 Peter Verswyvelen <bugfact at gmail.com>:
> >>> 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 <
> jefferson.r.heard at gmail.com>
> >>> 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
> >>>> Haskell-Cafe at haskell.org
> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090402/35940470/attachment.htm