Am I overlooking some subtle semantic differences? To me, it looks like (non-composable) events can easily be implemented on top of callbacks using Control.Concurrent.Chan. And it shouldn't be too difficult to implement callbacks on top of events... If the above is true, then I'd say we implement callbacks first, we can easily add events later. Events look like a higher-level concept to me, as they seem to require concurrency to be meaningful. They could be added as an add-on-library, but IMHO we probably don't need them in the spec right now. Which leads us to another big question: Concurrency. The CGA should probably be safe to use from many threads at once (although many backends aren't, so the library would have to do a lot of synchronizing). Should callbacks for multiple clicks on one button really run concurrently, or should it behave like most toolkits for other languages? I know of no "conventional" toolkits where event handlers for one event source are run concurrently. It sounds dangerous, but it might have advantages. Cheers, Wolfgang