[PEAK] Laziness, terminology, and the Trellis API

[Sergey Schetinin]

Regarding the terminology, I think renaming 'transient_variable' to 
'signal' would be great, so what was 'receiver' becomes 'signal', 
'discrete'/'compute_transiently' could be 'emit', 'emitter', 'transmit' 
  or some variation on that.

Also, some way to recompute the rule only if there is a signal present 
would be great as well. 'if self.signal is not None:' works, but often 
seems unnecessary.

'resets_to' could be renamed to 'nosignal' as well, not much typing 
saved, but mnemonically a much better choice IMO.

Now I also think 'react' is a much better choice than 'observe' or 
'perform' as well.

'variable', 'compute' and 'maintain' still seem to be the perfect 
choices though.

Phillip J. Eby wrote:
 > So out of all that, I kind of like:
 >
 > * variable - hold a value that can be set
 > * compute - calculate a value, no side-effects (i.e., lazy/cached)
 > * maintain - keep one or more values current within the Trellis
 > * maybe_maintain - optionally maintain
 > * perform - do actions in the outside (non-Trellis) world
 > * maybe_perform  - optionally perform
 >
 > Of course, the first four items above can also be discrete (transient),
 > so we also need:
 >
 > * transient_variable - (called "receiver" today)
 > * compute_transiently  - (@discrete, except also lazy)
 > * maintain_transiently - (@discrete today)
 > * maybe_maintain_transiently - (@optional @discrete today)