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

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

prj@po.cwru.edu (Paul Jarc) writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> 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.

The old stuff will not be removed from Guile, but from the main body
of the manual.

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

Yes, right.  What about inline functions?  We already use them for
scm_cell and scm_double_cell, we can use them for converting fixnums
as well, for example.

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

I see.  You will still get the name of the subr that has been called
directly from Scheme, but not any names further down the call chain.
For example,

  SCM
  subr2 (SCM x)
  {
    ... scm_to_int (x) ...
  }

  SCM
  subr1 (SCM x)
  {
    return subr (x);
  }

  guile> (subr1 #f)

will cause something like

  In procedure subr1 in expression (subr1 #f):
  Wrong type argument: #f

instead of

  In procedure subr2 in expression (subr1 #f):
  Wrong type argument in position 1: #f

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

If you really want to check for #t, you should use 'eq?', I'd say:

  scm_is_eq (x, SCM_BOOL_T)

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

Yes, well.  I haven't made my mind up yet, but I tend to just use
scm_is_true and scm_is_false.  It's not a big problem to be a little
unsymmetric, I'd say.


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