Mark H Weaver <m...@netris.org> writes: > Here's an implementation of SRFI-111 Boxes for stable-2.0. > What do you think? > > Mark
Has it been considered to coalesce the box type with Guile's "variable" type? I can see two concrete differences: * External representation (*not* specified by SRFI-111) * Variables can be "unbound" (empty), boxes can't So we could get away with making the box API consist of aliases to a subset of the variable API and still conform to SRFI-111. This would eliminate type-disjointness between variables and boxes, make boxes print with #<variable, make objects exist that are box? but error when passed to unbox, and eliminate the extra record type. And as a more "volatile" point, it would make boxes perform possibly a bit faster now (direct C implementation, whereas records all have some overhead as of now AFAIK), but a bit slower in theory given a perfect record-type implementation (needn't check for boundness during `unbox'). I suppose that's more cons than pros after all? And very sorry if I'm bikeshedding, I thought this was worth at least a mention and a quick survey. Taylan
