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

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

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

Yes.  For more help, people probably need to use the debugger, or a
backtrace, or maybe need to instrument their code.

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

The return value can not be out of range since a SCM can represent all
values that fot into an 'int'.  (I know that you know that ;-)

> But, this can certainly easily be fixed by changing the error
> message to 'value out of range'.

Yes, not using "argument" in the error message is likely an
improvement.  Not all values that are wrong are thought of directly as
arguments by the user.  For example, the wrong value might be an
element of a list that is an argument.

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

Yes, that would be very good.  Right now, we only give argument
positions, and that as good as argument names.  With scm_to_int, we
the argument positions are not included in the error message, which is
a clear drawback.

Right now, I hope that the debugger and the backtrace mechanism can be
used to recover this lost information.  In addition to giving a
backtrace that shows how the flow of control has reached the point of
error, it can also show how the erroneous value has reached this
point.

That is, the backtrace would highlight occurences of the wrong value
in the printed backtrace.

(The obvious problem is that immediate values can not be reliably
found, but hopefully this is not a big problem if we are careful to
acknowledge this uncertainty in the output, i.e, when we state that
"the wrong value might be the second or third argument", say, for
immediates, instead of saying "it is the second one".)

I'll say more when I have toyed more with this idea.

> On what basis would the decision be taken? By asking people
> on the guile-devel and guile-user lists what they would prefer?

*cough*, I just did it my way!  The code is now in CVS head, comments
welcome!

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