Strategy for supporting GOOPS based numeric types

[Mark H Weaver <mhw@netris.org>]

Andy Wingo <wingo@pobox.com> writes:
>> SCM_NUMBERP, SCM_NUMP, and SCM_INEXACTP ought to be deprecated, and
>> replaced with internal versions.
>
> OK, but in master only please.

Yes, of course, makes sense :)

>>  They check only for representations
>> supported by the core implementation, and do not properly support GOOPS
>> numeric classes (part of an upcoming patch series I'm working on).
>
> I'm a little concerned about the impact goops numbers would have on
> making type dispatch slower, like
>
>     (cond
>       ((symbol? x) ...)
>       ((number? x) ...))
>
> How many different kinds of numbers are we talking about?

The sky's the limit.  Ideas of numeric types that might make sense to
implement are: arbitrary-precision floats, complex numbers with
arbitrary component types (these two I've already implemented),
fixed-point, decimal floats, intervals, or even "infinite-precision
reals" which lazily compute as many digits as you want on demand.

The point is, it seems to me that no matter how many representations we
add, there are good reasons why some people might want others.  I'd like
Guile to support experimental new representations of numbers.

> Would be nice to avoid having number? call a generic function.  Dunno.

Yes, I agree completely.  The solution I adopted in my preliminary patch
set is to allocate SCM_VTABLE_FLAG_GOOPS_3 for that purpose, and make it
a "Class flag" (see "{Class flags}" in goops.h).

#define SCM_VTABLE_FLAG_GOOPS_NUMBER SCM_VTABLE_FLAG_GOOPS_3
[...]
#define SCM_CLASSF_NUMBER        SCM_VTABLE_FLAG_GOOPS_NUMBER

That flag is automatically set for any class that is a subclass of
<number> (directly or indirectly).  So then I have a fast macro
SCM_GNUMBERP that's implemented as follows:

#define SCM_GNUMBERP(x) \
  (SCM_STRUCTP (x) && (SCM_STRUCT_VTABLE_FLAGS (x) & SCM_CLASSF_NUMBER))

scm_number_p is implemented as:

  return scm_from_bool (SCM_NUMBERP (x) || SCM_GNUMBERP (x));

The other numeric type predicates are implemented by dispatching into
GOOPS if and only if SCM_GNUMBERP is true.  For example, scm_real_p:

  if (SCM_I_INUMP (x) || SCM_REALP (x) || SCM_BIGP (x) || SCM_FRACTIONP (x))
    return SCM_BOOL_T;
  else if (SCM_GNUMBERP (x) && SCM_LIKELY (SCM_UNPACK (g_scm_real_p)))
    return scm_call_generic_1 (g_scm_real_p, x);
  else
    return SCM_BOOL_F;

Maybe there's a better way to do this, but at least this strategy only
slows things down noticeably when the object being tested is a GOOPS
object whose class is a subclass of <number>.

Another strategy would be to add a field of flags to the class VTABLE
which contains one flag for each numeric type predicate.

Thoughts?  Better ideas welcome :)

    Best,
     Mark