[PEAK] Laziness, terminology, and the Trellis API
maluke at gmail.com
Thu Mar 27 10:09:57 EDT 2008
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
'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
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)
More information about the PEAK