bug#24102: Use guile variable objects as SRFI-111 boxes.

[Mark H Weaver]

Hi Glenn,

"Glenn Michaels" <address@hidden> writes:
> Currently, guile's (srfi srfi-111) module ("mutable boxes") provides
> an implementation based on records with a single value field.
>
> Wouldn't it make more sense to re-export the functions make-variable,
> variable?, variable-ref and variable-set! from the guile core as box,
> box?, unbox and set-box! respectively?
>
> These functions have the same signatures and the same semantics as
> required by the SRFI-111 spec., and they appear to be significantly
> faster than the current record-based implementation.
>
> Moreover, SRFI-111 boxes and guile variable objects are clearly
> semantically the same thing.

Unfortunately, they are not quite the same thing.  Unlike SRFI-111
boxes, Guile variables are a union type: they contain an arbitrary
Scheme value, *or* they may be "unbound".  For such a simple data type,
this added complication is semantically quite significant.

As a result, some important properties of SRFI-111 boxes do not hold for
your proposed implementation.  For example, in SRFI-111, (box? x)
implies that (box-ref x) will not raise an exception, and this fact can
be exploited by a compiler to produce better native code for 'box-ref'
when the type of its argument is known to be a box.  In such cases, I
guess 'box-ref' can be implemented as a single load instruction, whereas
'variable-ref' will require a conditional branch.

Especially for such a simple and fundamental data type, I think it's
important to retain precisely the specified semantics, without *any*
additional complexity.  For this reason, I am opposed to this change.

What do you think?

    Regards,
      Mark