This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: SCM_VALIDATE_...


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]