Lazy slots

[Gilad Bracha]

Lazy slots are related to the concept of orthogonal synchronization.  See my recent blog post at:

https://gbracha.blogspot.com/2022/04/bitrot-revisited-local-first-software.html

The original plan for Newspeak involved a feature known as transient slots. The idea was that all slots not marked transient would be automatically persisted and sync'ed by the system.  Lazy slots look like

lazy s =  compute: 1 from: 2.

and behave a lot like transient slots, in the sense that they always have an initialization expression, which gets computed when the slots getter is first run, after which the result is stored in the slot and accessed as usual.

Transient slots were supposed to have the form transient s =  compute: 1 from: 2.  and behave the same, but in addition, whenever a sync occurred, they would be nil'ed out automatically, and so the next time they were needed they would be recomputed based on the latest up-to-date persistent data.

This lazy behavior is generally useful, regardless of orthogonal sync. One often has situations where a slot is to be initialized later than the object, and one writes an accessor for it that tests if it is nil and if so sets the slot, otherwise returning the slot value. This happens often enough that it seems worth generalizing from transient slots to lazy ones.

.

Now, when/if we finally implement orthogonal sync, we could simply annotate those lazy slots we want to be transient with metadata such as

lazy s (* :transient: *) =  compute: 1 from: 2.

and that would tell the system to nil them out.

As I said, these mostly work but there is some flakiness. The debugger exposes the implementation, whereas it really should hide it (much like it hides details of initialization used by factory methods).

The lazy slots support exemplars, but this is incomplete and tends to crash. Other quirks are likely.  In short, they aren't quite ready to use yet.