--- Michael Lazzaro <mlazz...@cognitivity.com> wrote:

I once worked on a CPU simulator, and in order to set watch values on
arbitrary memory we used a "key" value that, if present in simulated
memory, indicated that a search of the "watches table" was in order.

That key was chosen empirically, based on histogramming the ROM images
and active program state, and choosing the lowest frequency value.
Thus, the "fetch byte" primitive would automatically check and notify
whenever a 0xA9 was seen. (Sometimes it really meant 0xA9, other times
it meant "0x00, but halt execution".)

The same can be done here, if the internals folks can make the
assumption that the case is really uncommon. To wit:

For 'bit', the key value is (eenie, meenie, ...) '1'.
Any '1' value will trigger a search for undef bit values. Presuming
that bit values will not frequently be undef, the search should be
cheap and the storage requirements will be something on the order of

C + Num_undef_bits * sizeof(addr_t)

Which will be greater than one extra bit when few or no bit objects are
used, and will be very much smaller than one extra bit when many bit
objects are used.

In short:

It's possible, even easy, to implement ANY feature (properties, undef,
etc) for primitive types in this manner. It absolutely *IS* correct to
say "That's an implementation detail" and leave it to the internals
team to figure out HOW they want to do it.

So what's the difference REALLY?

=Austin

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2