This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: SCM_VALIDATE_...


Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> 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.

We *could* do it like that, but it seems so complex.  I think I'd
prefer it if <complex> and <comp-rep*> was the same class, etc.

I'd like to postpone this decision, though.

> (Mikael, in your version of the class tree, fixnums were a subclass
> of bignums.  I assume this was a mistake?)

Yes.

> 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*>

I get your point, and agree that we should perhaps not seal <integer>.

This brings up another interesting question:

If we extend the numerical tower with a new range type, we'll
currently have to specify a new set of methods for all numerical
operations.

It would be interesting if we instead could have some builtin system
for coercing, so that we only need to specify how to cast a certain
range type into some other type and back.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]