This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: SCM_VALIDATE_...
- To: Jim Blandy <jimb at savonarola dot red-bean dot com>
- Subject: Re: SCM_VALIDATE_...
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Thu, 25 May 2000 18:58:13 +0200 (MEST)
- cc: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>, Guile Mailing List <guile at sourceware dot cygnus dot com>, djurfeldt at nada dot kth dot se
On 25 May 2000, Jim Blandy wrote:
>
> I'm coming in rather late on this discussion, so I may be missing the
> point, but:
>
> Within the interpreter, it's useful to have predicates that ask about
> a number's *representation*, not its *value*. The Scheme-level
> predicates only ask about numbers' values, never their
> representations.
This distinction makes sense, but:
> So we could have a set of predicates that ask about representations:
>
> SCM_REP_FIXNUM_P
> SCM_REP_FLOAT_P
> SCM_REP_BIGNUM_P
> ...
>
> and a set of predicates that ask about values (as the Scheme functions do):
>
> SCM_INTEGER_P
> SCM_RATIONAL_P
> SCM_REAL_P
> SCM_COMPLEX_P
> ...
>
> SCM_EXACT_P
> SCM_INEXACT_P
>
> In general, I think user code really wants the latter set of
> functions. [...]
If we plan to provide macros for the value oriented point of view we
have to be careful: When goops is integrated, any value based predicate
may be broken as soon as someone adds an additional representation for a
certain class of numbers. Example: A goops class that represents inexact
reals by using floats, in addition to the current representation as
doubles. Suddenly we have a situation, where SCM_REAL_P and
"real?" behave differently, except we add a call to the corresponding
generic dispatch routine to the macro's definition.
This is, obviously, a more general problem: The whole macro stuff (as it
is now) will only work for a certain 'built in' set of representations for
everything, except every macro is extended by the corresponding generic
function call.
Best regards
Dirk