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

[Jeff Heard]

On Thu, Apr 2, 2009 at 11:22 AM, Jules Bean <jules at jellybean.co.uk> wrote:
>
> Maybe I wasn't clear, and probably I'm being dense. I understand what you've
> done - I looked at the type declarations before commenting - but I don't
> understand why.
>
> Why is it useful to be able to use basic types without locking down 'a'?
>
> Why is it useful to have a value of type "Event FooBar" which, in apparent
> defiance of the FooBar parameter, actually contains a value of type Double?
>
> Jules
>

I'm assuming everyone won't want to start from scratch in creating all
their widgets and behaviours.  A bus contains only events of type 'a',
therefore all widgets and behaviours on that bus must use events of
type 'a'.  It is possible to run multiple buses at the same time in
the same program, and even possible to have them communicate between
each other (forkIO-ing the buses and attaching some arbitrary
behaviour that takes events from bus0, translates their types and then
puts them on bus1), and so that way you could use multiple types, but
I don't see a problem with a user having to read the documentation and
understand that an Event of type a contains data that is a variant
including type a.  How is it useful?  Consider the following widgets:

commandLineArgsWidget :: Widget a
commandLineArgsWidget = getArgs >>=
    \args -> produce' "Environment"
                      "CommandLineArgsWidget"
                      "argv"
                      Persistent
                      [EStringL args]

environmentWidget :: Widget a
environmentWidget b = getEnvironment >>=
    mapM_ (\(k,v) -> produce' "Environment" "EnvironmentWidget" k
Persistent [EString v] b)

progNameWidget :: Widget a
progNameWidget b = getProgName >>=
    \v -> produce' "Environment" "ProgramNameWidget" "ProgramName"
Persistent [EString v] b

As the library stands right now, I can take these widgets and put them
in a module and include them as part of the Buster library, and they
can be used pretty arbitrarily.  I can see being more semantically
pure and changing Event a to contain data of type a instead of data of
type [EData a], in which case the type signatures would look like
this:

progNameWidget :: WIdget [EData a]

and so forth to be compatible with Bus [EData a], but I think that in
the end so many widgets will reuse the EData type that it's just as
well to make it part of the Event rather than force the user to be
explicit about it every time.  But if I'm generally disagreed with
about this, I can change it -- I'm pretty neutral about it, to be
honest.

-- Jeff