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

[Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>]

Marius Vollmer wrote:

>  Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> 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



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel