Hi Glenn,
"Glenn Michaels" <gmicha...@safe-mail.net> 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
