It is parametrically polymorphic in a. And no, it's an arbitrary
decision, BUT... it allows me and other users to define generally
useful behaviours and widgets to package with the library using the
basic types without locking down 'a'. The EventData type looks like
this:
data Event a { ..., edata :: EData a, ... }
data EData a = EChar Char
| EString String
| EStringL [String]
| EByteString ByteString
| EByteStringL [ByteString]
| EInt Int
| EIntL [Int]
| EDouble Double
| EDoubleL [Double]
| EBool Bool
| EBoolL [Bool]
| EOther a
| EOtherL [a]
Now, given that arbitrary decision, I'd be willing to modify Event so
that it is parametric on 'a' without EData and include EData as an
"example" binding for 'a' if the user chooses to use it. However, I
foresee most behaviours and widgets that are "generally useful" to be
dependent on this type, which is why I made it a basic part of Event.
-- Jeff
On Thu, Apr 2, 2009 at 11:05 AM, Jules Bean
Jeff Heard wrote:
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.
That sounds the opposite of general. That sounds specific. (Int, String, Double, ByteString as well as a user-defined type....).
Can you explain the reason for the EDouble, EString (etc.) alternatives as opposed to making the event simply (parametrically) polymorphic in "a" ?
Jules