Kulla API changes: shifting to events

[Brian Goetz]

> It will have event registration and at least initially and probably
> permanently a List of events would be returned by eval() -- presumably
> with value/exception -- and by drop().

There are a few degrees of freedom in event/listener management.

  - Are events unicast or multicast?  (i.e., what does it mean if you 
call onEvent(Consumer<Event>) twice?  does the second call replace the 
first, or do both listeners get the event?)
  - If events are multicast (the most common interpretation), how do you 
unsubscribe?
  - How fine-grained are event subscriptions?

You've talked about leaving room for a "plugin" mechanism in the future. 
  Presumably the plugin would be provided access to the REPL state.  And 
then it might want to attach its own listeners.

The historical view of listener support (from the Beans days) relies on 
the identity of the listener; if you pass a listener to unsubscribe(), 
it is removed from the list.  But, this is not a very lambda-friendly 
mechanism, as you can't count on the identity of a lambda.  So a more 
lambda-friendly API might be:

     SubscriptionToken subscribe(listener)
     void unsubscribe(subscriptionToken)