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

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

Marius Vollmer wrote:

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

No misunderstanding. I fully agree with you that the code should never
silently work with incorrect values. However, if scm_to_int throws an
error 'wrong type argument' or 'argument out of range', this is still not
too much of a help in many cases.

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

And it is already an example that 'argument out of range' is not a
very good message if the return value is out of range. But, this can
certainly easily be fixed by changing the error message to 'value out
of range'.

Still, I am wondering whether a user of this function would not be
happier if instead of 'argument out of range' or 'value out of range'
the message would be one of
  'process id argument to kill out of range'
  'signal argument to kill out of range'
and if you are not really sure what posix_kill returns
  'return value of system function kill out of range'.


Looking again at the solution that I had suggested:
  <type> scm_to_<type> (SCM value, int *success)
might even be extended: Instead of returning just true or false
for success, the following, more fine-grained results could be
given:
  typedef enum {
    SCM_TO_INTEGER_OK,
    SCM_TO_INTEGER_UNDERFLOW,
    SCM_TO_INTEGER_OVERFLOW
  } scm_t_scm_to_integer_conversion_state;
Depending on the way the scm_to_<type> functions for
integer types would be implemented, this could be provided
at almost no cost. It might be helpful for code that decides
to fall back to the minimum/maximum value in case of an
underflow/overflow.

(This is yet another design alternative.)


But, all in all I could live with the decision to have the range-
checking functions separate.

On what basis would the decision be taken? By asking people
on the guile-devel and guile-user lists what they would prefer?
This would give us a better indication of what the typical case
really is. Everything else is just guessing and taking decisions
on a maybe unsufficient knowledge base.

Best regards,
Dirk



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