
Alright, updated it to extract EData from the Event type and make it
separate. Basically, now all type signatures
Event a
Widget a
Behaviour a
should read
Event [EData a]
Widget [EData a]
Behaviour [EData a]
for backward compatibility.
On Thu, Apr 2, 2009 at 11:53 AM, Jeff Heard
On Thu, Apr 2, 2009 at 11:22 AM, Jules Bean
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