Additions to the gh_ interface.

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

Hello everybody.

I just realized, that the R*RS predicates complex?, real?, rational? and
integer? don't have an C equivalent. These are probably easily provided.

However, there is also need for a test, whether a Scheme number is
convertible to a C builtin number type. I assume that such a test will
only be required in combination with the actual conversion. Therefore, I
suggest the following solution: 

long gh_scm2long(SCM obj);                /* the current function */

long gh_safe_scm2long(SCM obj, int* flags);   /* the new function */

The status of the conversion could be returned in the flags variable.
(Instead of int, an enumeration could be used, or a typedef, ...)

One could even think of removing the old conversion function and only use
the alternative solution: If the user is not interested in the flags, a
NULL pointer can be passed. An implementation could look like (the
internal conversion functions should obviously be renamed and not belong
to the gh_ interface):

inline long gh_scm2long(SCM obj, int* flags) {
    if (flags) return gh_safe_scm2long(obj, flags);
    else return gh_unsafe_scm2long(obj); /* the old function, renamed */
}

With an optimizing compiler, there is no overhead between the current
call gh_scm2long(o) and the changed call gh_scm2long(o, NULL). It's a
matter of taste, but I think this would be the cleanest solution, although
it would break existing code.

Flags could be (possibly in combination):
OVERFLOW, SIGNEDNESS, TYPE_MISMATCH, ...

Not all of these have to be errors: For example, a TYPE_MISMATCH could
mean that a rational was converted to a long. Guile could provide a
sensible default (e.g. the quotient) and still report the TYPE_MISMATCH
(the quotient, however, could lead to an OVERFLOW). Similar for
Scheme-real --> long etc.

Best regards, 
Dirk Herrmann