Re: SCM_VALIDATE_...

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jim Blandy <jimb@savonarola.red-bean.com> writes:

> > The only case where *a* value type of an object can differ from *the*
> > representation type is when the class representing the representation
> > (ehrm..) is a proper subclass of the class representing the value
> > type.
> 
> If I understand you, this makes it difficult to introduce new
> representations which have more expressive power than an existing
> representation.  If you have an existing class hierarchy like:
> 
> <number>
>   <complex>
>     <real>
>       <rational>
>         <integer>
>           <bignum>
>             <fixnum>
> 
> and you want to introduce a new type like (say) <algebraic>, which can
> represent things like (sqrt 2) exactly, it must be a subclass of
> <real>, but a superclass of <rational>.  We can't add that to the
> system without modifying the definition of <rational>.  
> 
> So it looks to me like your suggestion leads to a rigid numeric tower.
> I thought one of the advantages of OOPS was that ordinary code could
> seamlessly extend the numeric tower.

(I haven't thought deeply about this.  On the other hand I want to do
 other Guile things when I get Guile time instead of thinking about
 this, so I just give my immediate thoughts.)

Firstly, I'm not sure if it is a good idea to allow this kind of
extension of a system class hierarchy.  What do the Kiczales rules say
about it?

If we don't allow it, we can add algebraic numbers as a side
hierarchy, thus allowing multiple representations.  (Is this what you
were thinking about?)  Note that this doesn't violate the rule above
if we change "*the*" to "*a*".  We can make such a change without
causing performance penalties for type check macros.

If we allow redefining <rational> (note that we can allow this, but
still disallow subclassing <integer>), there's no problem at all.