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

[Mark H Weaver]

"Glenn Michaels" <address@hidden> writes:

> Sorry for the delayed response.
>
> Mark H Weaver <address@hidden> writes:
>> > 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
>
> You're right. They aren't exactly the same, it would be more correct
> to say that boxes are equivalent to bound variables. Thus box? should
> be defined as:
>
> (define (box? o) (and (variable? o) (variable-bound? o)))
>
> That way, (box-ref o) is guaranteed to work whenever (box? o) holds.

The problem is, a variable that is bound can later become unbound.  In
SRFI 111, if (box? x) is _ever_ true, then it will always remain true.
With your proposed definition above, that is not the case.  Whether a
variable is bound is part of its mutable state.

> If a future guile compiler can implement boxes more efficiently in a
> different representation, there's nothing to stop you switching to
> that representation when the time comes.

If we adopted your suggestion, it's likely that some users would come to
rely on the fact that boxes are actually variables, with this extra
"feature" of supporting the "unbound" state, and then we wouldn't be
able to remove that feature without breaking existing code.

>> 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.
>
> With respect to what you say about compiler optimizations: In order to
> implement a given call to unbox with a single load instruction, the
> compiler would have to prove that the argument is a box, i.e. that it
> satisfies the box? predicate.

Right, and the compiler that will be in Guile 2.2.x already has the
ability to perform this kind of type inference.

> You could also implement calls to variable-ref with a single
> load instruction in cases where the compiler can prove that the
> argument is a bound variable, i.e. that it satisfies
> (and (variable? o) (variable-bound? o)) -- precisely the definition of
> box? above.

It would very rarely be possible to prove that in practice, because the
"bound"-ness of a variable can change with time, and because in Scheme
it is very common to call procedures whose body is unknown at
compile-time, during which the bound-ness of the variable could change.
This is not a problem with SRFI-111 boxes, which will never change to
anything else.

> However, this discussing is academic insomuch as AFAICT the
> current guile compiler currently performs neither optimization.

As I wrote above, the current guile compiler can already do this kind of
type inference, although it does not currently do this for boxes.
However, we can already anticipate having native code generation in the
next couple of years, and we must keep boxes semantically simple so that
our future compiler will be able to generate good code for this very
important fundamental type.

Does that make sense?

       Mark