[Prev][Next][Index][Thread]
Re: class <machine-word>
At 3:00 PM -0800 11/6/01, Peter S. Housel wrote:
>Can the <machine-word> class be a subclass of <abstract-integer>? The
>documentation says only that it is a subclass of <object>, but given that
>odd?, even?, zero?, positive?, negative?, \= , \<, min and max are defined
>on <machine-word> it makes sense that it ought to fit into the existing
>numeric heirarchy.
>
>Cheers,
>-Peter S. Housel- housel@acm.org http://members.home.com/housel/
I'm going to assume you are talking about the Fun-O class <machine-word>
(or perhaps a gwydion class which is supposed to be compatible with the
Fun-O class).
I was originally going to reply something along the lines of "it certainly
should not be a subclass of <abstract-integer>." However, some more research
convinces me that while that is correct, it is not necessarily obvious.
(Some early versions of what became the <machine-word> design actually
specified that the relationship between <machine-word> and <abstract-integer>
was explicitly undefined! Since I wrote all of those various versions, the
answer to your question was certainly not obvious to me back then.)
I think <machine-word> should be disjoint from <abstract-integer>. While
they have some common operations, <machine-word>s are really not integers
in a semantic sense. They are instead blobs of raw, seething bits,
supporting some operations that make them useful for implementing things
like <abstract-integer> and its various subclasses. In the vast majority
of code, having a <machine-word> appear in a context where an
<abstract-integer> was expected would probably indicate that something had
gone seriously wrong somewhere.
This argument applies toward placing <machine-word> somewhere highter in
the numeric hierarchy (though perhaps less strongly as one moves higher).
There was some discussion of having it be a subclass of <number>, but that
class seems to be pretty vestigial in Dylan, and so there is little
distinction between putting it there and putting it under <object>.
References: