Per Bothner scripsit:

> My first question is: what is the relationship between boxes and
> promises?  Is a promise a kind of box?  I.e. a promise is a box that
> can only be set once?  Are they both subtypes of something else?
> Would you use a box to implement a promise?

I don't think so.  A promise involves three things: the delayed
function, the forced value, and whether the forced value exists.  You
can collapse the first two into one variable, but you still need the
third, because you can't rely on the forced value not being a procedure
in the general case, so you can't collapse all three.

Alternatively, you can use a magic value to represent an unforced value,
but then you still need somewhere to keep the procedure.

> The "auto-boxing" section clearly has parallels with similar optional
> features of promises, so there a clear connections.  It's surprising
> they're not actually discussed.

It's more of an analogy, as between vectors and bytevectors, only not as
similar for the reasons given above.

> See this discussion of "blank promises",
> which is even more of a "set-once" box:
> http://www.gnu.org/software/kawa/Lazy-evaluation.html#Blank-promises

I'll look at that again when we consider concurrency.

> Also, what about more general types of boxes.  For example computed
> boxes, which are defined in terms of getter/setter functions.

I think this can be handled from the inside out, so to speak, by adding
`unboxer` and `box-setter` HOFs that curry `unbox` and `box-set!`.  Does
that do what you have in mind?

> Or being able to register a callback function ("listener"), which is
> called when the value in the box is changed.  In some models you can
> register arbitrary numbers of listeners.

That's interesting:  I'll think about it further.

--
John Cowan                              <xxxxxx@ccil.org>
            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org