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

[Paul Jarc]

Marius Vollmer <address@hidden> wrote:
> Thanks, do you think it worth implementing (and thereby deprecting the
> old stuff)?

As long as the old stuff isn't removed gratuitously, I'd say go for
it.  But maybe profile some code both ways to see if the function call
overhead is significant.  The current macro type predicates just
examine the bits of the SCM value, without even following a pointer,
right?  OTOH, these functions could be implemented as macros too, if
the performance gain was significant, so that shouldn't necessarily
affect the decision of whether to use the new API.

>> I have some code that benefits from having the subr name in the
>> exception - in the case of 'system-error, it walks the stack to find
>> and report the call that failed, including arguments.
>
> Can you give a quick example?  (Does it walk the C stack and prints
> the failed system call?)

No, just the Scheme stack.  See exit-for-system-error in the attached
file.
guile> (exit-for-system-error "myprog" (lambda () (delete-file "/foo")))
myprog: unlink("/foo"): No such file or directory

(There's a hard-coded mapping of "delete-file" -> "unlink", etc.)

> Hmm, I don't think we should do that.  There is nothing to be gained
> in treating SCM_BOOL_T specifically here.

Well, maybe just a little bit special - scm_to_bool could map #f -> 0,
#t -> 1, everything else -> 2.  That could be useful for something
like format.

> Maybe we should't have scm_to_bool and scm_is_bool at all?
> scm_is_true (and maybe scm_is_false) should suffice.

Consistency with the functions for other types would dictate that
there should be only is_bool and to_bool, and not is_true or is_false.
OTOH, each of them could help code readability in different cases, so
I'd include them all.  None of them should be very hard to write or
maintain.


paul

errors.scm
Description: Text document