[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GH replacement proposal (includes a bit of Unicode)

From: Dirk Herrmann
Subject: Re: GH replacement proposal (includes a bit of Unicode)
Date: Sat, 15 May 2004 12:18:17 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220

Marius Vollmer wrote:

 Dirk Herrmann <address@hidden> writes:

> Alternative 1: * change the functions in the following way: <type>
> scm_to_<type> (SCM value, int *success) Instead of signalling an
> error, *success indicates whether the value can be represented. If
> *success is 0, the returned value is unspecified. If success is
> NULL, an error is signalled for the case that the value can not be
> represented.

 I don't like this very much; I want the fundamental functions to be
 as simple as possible. Passing NULL or (worse), having to pass a
 valid pointer add significant noise to the code, and I would like to
 avoid this.

> Alternative 2: * provide the following additional functions: <type>
> scm_to_<type>_2 (SCM value, int *success) I have not yet an idea
> for a good name, thus I have just added the _2 postfix. Alternative
> 3: * provide the following additional functions: int
> scm_fits_<type> (SCM value); Return 1 if the value can be converted
> to a C value of type <type>, 0 otherwise. If scm_fits_<type>
> returns 1 for some value it is guaranteed, that a subsequent call
> to scm_to_<type> does not signal an error.

 In my opinion, keeping type tests and type conversions separate is
 the cleanest approach. Testing whether an integer fits a given C
 type should be quite seldom: what do you do when it doesn't fit?

 So, I like alternative 3 best; and I think it will suffice to provide
 only two functions:

 int scm_is_unsigned_integer (SCM val, scm_t_uintmax min,
 scm_t_uintmax max);

 int scm_is_signed_integer (SCM val, scm_t_intmax min, scm_t_intmax

Yes, when choosing alternative 3, this would be a nice solution. It might
also make sense to add these functions if one of the other alternatives
would be chosen.

> The disadvantage of alternative 3 is, that for a lot of code the
> checking will have to be performed twice: The user will first call
> scm_fits_<type> and then scm_to_<type>. Both, however, will check
> whether the value fits.

 Yes, but I don't want to worry about this yet, since I really think
 this kind of range checking will not be done significantly often.

I doubt that this is true. The only scenario, where I would _not_ perform
this kind of check is, when I have the full control over all the code that
generates the numbers, and when I know my algorithms well enough to
know that no overflow can occur.

In all other cases, I would at least prefer to print out a warning, at which
place I have received incorrect value. For example, if the number comes from
some extension code provided by the user of my application: It is good
style to indicate clearly, what the user's code did wrong. That is, whether
or not you can do something about a bad value, you still want to know it,
at least to be a little bit more user friendly in your error messages.

And, as I had clarified in a later mail:
DH>> I would even go further and simply disallow the passing of NULL. It's
DH>> just another asymmetry and magic number. The rule woule be, that (if
DH>> the SCM argument is of the correct type), the caller always has to
DH>> provide a valid pointer for success. On the contrary, if the SCM argument
DH>> is not of the correct type, an error should be thrown. The success
DH>> argument is therefore only for overflow checks, not for type checks.
DH>> This is symmetric with the other conversion functions.

It may be that we end up with different opinions here. That's OK, but for
the final decision I suggest to check what after the discussion the majority
of developers (or users) prefers.

>> - SCM scm_from_complex_double (double re, double im); - double
>> scm_to_real_part_double (SCM z); - double scm_to_imag_part_double
>> (SCM z); [...]
> We should be prepared to provide conversion functions for the new
> ISO-C99 types float _Complex, double _Complex, long double
> _Complex, float _Imaginary, double _Imaginary and long double
> _Imaginary. Thus, the naming scheme used above seems a bit
> confusing if we later expect a function scm_from_double_complex to
> be added.

 Hmm, tough. What about removing scm_from_complex_double completely
 and tell people to use

 scm_make_rectangular (scm_from_double (r), scm_from_double (i))

 instead? The scm_from_double_r_double_i scheme looks a bit too
 complicated to me.

No problem with that. Let's just wait if there is lot of demand for something
more efficient, we can re-think the issue then.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]