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

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

>>  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.

Hmm, there might be a misunderstanding somewhere: they way I want it,
scm_to_int would either produce a correctly converted 'int', or would
signal an error.  The error might be a 'wrong type argument' one when
a non-integer has been passed to scm_to_int, or it might be a
'argument out of range' one, when the integer doesn't fit into an
'int'.  There would not be the case that code would silently work with
incorrect values.

Given this behavior, I still think that explicitely checking whether a
SCM value fits into a 'int' will not be done often.  When the value
doesn't fit, what do you do?  You could print a warning, but wouldn't
the error produced by scm_to_int be better?

You could try to explicitly deal with non-int values, but how?  When
you have a method to deal with non-ints why not use it always?

Maybe it is much less efficient, so there really is a reason to do
range checks.  But I believe that this situation happens both
infrequently and when it happens, the second done by scm_to_int is not
a problem.

When it really is a problem, tho, it is likely worthwhile to use the
internal stuff of libguile directly, such as SCM_INUMP, SCM_MAKINUM,
SCM_INUM, etc.  This will be less portable across versions of Guile,
of course, but when that is what it takes...


I see the typical use of scm_to_int etc to be in glue code, like

  SCM
  posix_kill (SCM pid, SCM sig)
  {
    return scm_from_int (kill (scm_to_int (pid), scm_to_int (sig)));
  }

That is all it should take to wrap 'kill'.

>> >> - 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.

Yes.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405