anchor.diff:  
   Nope! That's intentional. These are your classes, and I don't want to clutter up your API unnecessarily. `#on` and `#emit` are provided as conveniences for common actions. Anything else you need, you can get to via the `Emitter` returned from `#events`.
   
  -=== Constraining event types
  +### Constraining event types
   
   *I see that un-handled events are just ignored. Doesn't that make it easy to miss events because of a typo in the name?*
   
  
positive.code: 
  In this example, the `HtmlFormatter` is only subscribed to poem events for the duration of the call to `#recite`. After that it is automatically detached.
  
  === Replacing return values with events
  
  *This is interesting. I can see this being useful for more than just traditionally event-generating objects*
  
  
negative.code: 
  You can run the proof-of-concept benchmark for yourself! It's in the `scripts` directory.
  
  ### Managing subscription lifetime
  
  *You know, it occurs to me that in the `Poem` example, it really doesn't make sense to have an `HtmlFormatter` plugged into a `Poem` forever. Is there a way to attach it before the call to `#recite`, and then detach it immediately after?
  
  