[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
max);
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,
Dirk
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/12
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/17
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/17
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/17
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/17
- Re: GH replacement proposal (includes a bit of Unicode), Marius Vollmer, 2004/05/17