Re: ratio implementation

[Dirk Herrmann]

Bill Schottstaedt wrote:

> Looks straightforward, but I may not get around to it right away.
> Should I wait for Dirk's type-related changes?

Just for your information: I have submitted a patch which does the first 
part: Introducing scm_tc7_number and turning bignums, reals and complex 
numbers from smobs into subtypes of scm_tc7_number. The patch, however, 
is quite simplistic and does not yet optimize the way the subtypes of 
scm_tc7_number are allocated. It should nevertheless provide the 
type-system infrastructure for easy integration of the fraction type.

> > A ratio is exact, while a real is not.  Thus, I'd say that ratio? is
> > not really necessary.  There should be no reason to add anything eyond
> > R5RS for ratios.
>
> Ok -- "exact?" used to return #f for 3/4 -- hence the confusion.
>
>
> >> An alternative would be to make "rational?"  rational.
> > That would violate R5RS, wouldn't it?
>
> I don't think so.  You are allowed to make rational? be the same
> as real?, but you can also distinguish them.  My druthers would
> be for rational? to return #t for a ratio, #f for a float.
> Why have it at all if it is just a synonym for "real?"? 

Just a side note: We should in guile distinguish between the internal 
representation of values, and their mathematical meaning. For example, 
fixnums and bignums are two representation of integer types. They 
should, however, also report #t when queried about being rational, real 
or complex, since they are elements of all these sets. When introducing 
exact rationals, which are represented internally as a pair of two exact 
integer values, we should not name them rationals, but, for example, 
fractions.

The reason I mention this is that I want to avoid a macro SCM_RATIONAL_P 
to be introduced: The meaning of such a macro would not be clear, since 
it might either be expected to return the equivalent of rational? or 
just return true if an object was detected with an internal 
representation of a fraction.

A nice set of macros to check for numbers of a specific internal 
representation could be (names are just given as examples):

SCM_FIXNUM_P (currently named SCM_INUMP)
SCM_BIGNUM_P (currently named SCM_BIGP)
SCM_FRACTNUM_P
SCM_FLOATNUM_P (currently named SCM_REALP, which is confusing)
SCM_FLOATCPLXNUM_P (currently named SCM_COMPLEXP)

while a nice set of macros for testing for a mathematical meaning could 
be (names are probably acceptable):

SCM_EXACT_P
SCM_NUMBER_P
SCM_INTEGER_P
SCM_RATIONAL_P
SCM_REAL_P
SCM_COMPLEX_P

In the long term, we should rethink our current set of confusing names. 
For the short term, we should at least avoid to introduce more confusing 
terms, especially when introducing the new internal representation of 
fractions.

Best regards
Dirk Herrmann