Re: scm_num2float() ?

[Martin Baulig]

Dirk Herrmann <address@hidden> writes:

> Since 1.6 is not officially out yet, deprecating something in 'stable'
> allows to immediately remove it from 1.7 :-)
> 
> But, two other points with respect to numbers and conversions:
> 
> 1) Type conversion for some C type T requires the conversions T->number
> and number->T.  The number->T conversion should do some range checking to
> see, whether the number fits into the desired range.  From a C programmers
> view, however, it should be possible to check in advance whether a
> conversion number->T would work, because otherwise it is necessary to set
> up an error catcher or do the range check by hand, using some scm_less_p
> checks.  Since this is inconvenient, IMO together with the conversions
> T->number and number->T we should provide some number_fits_into_T_p
> predicate.  (Then, again, one could argue that number->T wouldn't need to
> do the range checks, because the user is responsible for doing them.  
> Another alternative is to provide two variants of the number->T conversion
> function:  A type and range checking one, and one that does no checks.)

Hmm, but isn't the most common use of number->T is when you get a scheme
value as argument to some C function - and in this case you want to use the
default error catcher on the scheme level anyways ?

The only other situation I can imagine where you may want to use number->T
is when you call some scheme code from C and want to check the return value,
but in this case you normally need a custom type checking anyways.

> 2) Given that we agree on 1), we end up with three (or four) functions for
> type conversions for each C type.  Assuming we want to consider the C
> types char, uchar, short, ushort, int, uint, long, ulong, float, double,
> ptrdiff_t, size_t, long long and ulong long, this gives 42 (or 56)
> conversion functions.  This is just overkill, IMO.  I think we should
> restrict ourselves to the types long, ulong, double, ptrdiff_t, size_t,
> long long and ulong long and have the users check themselves whether for
> example a ulong value received from scm_num2ulong fits into a character
> which can easily be done using the UCHAR_MAX macro.

Hmm, after looked at how it's done right now, it seems to me like we're
currently doing the range checking twice: the scm_num2something() functions
check their arguments and throw an exception if they're out of range - but
the VALIDATE scripts do a range checking as well.

So basically we have a

   SCM_VALIDATE_SOMETHING_COPY(pos, var, cvar) \
        do { \
                SCM_ASSERT (var_is_ok (var), pos, var, FUNC_NAME);
                cvar = scm_num2something (var);
        } while (0);

so the SCM_ASSERT() checks for the type and scm_num2something() does it
a second time.

So I start to doubt the usefulness of the VALIDATE macros - I think it'd be
more useful to have macros which just do the type checking, it's not so
hard to type SCM_ASSERT().

-- 
Martin Baulig
address@hidden (private)
address@hidden (work)