This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: SCM_VALIDATE_...
- To: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Subject: Re: SCM_VALIDATE_...
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Fri, 26 May 2000 11:27:40 +0200 (MEST)
- cc: Jim Blandy <jimb at savonarola dot red-bean dot com>, Guile Mailing List <guile at sourceware dot cygnus dot com>, djurfeldt at nada dot kth dot se
On 25 May 2000, Mikael Djurfeldt wrote:
> Also note that I didn't say we should freeze te entire hierarchy. I
> *do* think it would be good t freeze <integer>, <fixnum>, and,
> <bignum>, though.
I'm a little sceptical about whether it makes sense to freeze integer. I
understand the point about fixnums and bignums, because these are leaves
in the class tree corresponding to implementations. As I understand it, a
class tree might then look as follows:
<number>
<complex>
<comp-rep*>
<real>
<float*>
<double*>
<rational>
<rat-rep*>
<integer>
<bignum*>
<fixnum*>
Types with * denote representations, some of which don't even exist
yet. (Mikael, in your version of the class tree, fixnums were a subclass
of bignums. I assume this was a mistake?)
If we disallow subclassing of integers, then we would, for example,
disallow the implementation of a modulo-arithmetic type as an additional
representation besides bignums and fixnums. Also, integer range types
like n-bit integer values (like for uniform vectors as defined in some
SRFI) or integers from a certain interval etc.
So, I think it would be a loss to disallow subclassing of integer. Maybe
an intermediate class <guile-integer-rep> or so which covers only guile's
internal integer representations would help?
<number>
<complex>
<comp-rep*>
<real>
<float*>
<double*>
<rational>
<rat-rep*>
<integer>
<user-int-rep1>
<user-int-rep2>
<...>
<guile-integer-rep>
<bignum*>
<fixnum*>
Best regards
Dirk