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

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

Marius Vollmer wrote:

>Sooo, right now I'm wembleying towards having
>
> scm_is_true   --- return 0 for #f, 1 for everything else
> scm_is_false  --- return 1 for #f, 0 for everything else
>
> scm_is_bool   --- return 1 for #t and #f, 0 for everything else
> scm_to_bool   --- return 0 for #f, 1 for everything else
> scm_from_bool --- return #f for 0, #t for everything else
>
The names scm_is_true and scm_is_false don't fit into the schema, since 
true and false are no types. I am not sure if this is intentional or 
just an oversight. Further, if implemented as above, scm_is_true does 
not bring additional benefit and is confusing, since scm_is_false checks 
for #f, while scm_is_true checks for not-#f. But, there is still not yet 
any function that checks for #t. To do so, you would first have to call 
scm_is_bool and scm_is_true afterwards.

>Is there an advantage of having instead
>
> scm_to_bool   --- return 0 for #f, 1 for #t, else signal error
>  
>
This is certainly the most symmetric approach. If this approach was 
used, then (some maybe different named equivalent of) scm_is_true and 
scm_is_false (checking for exactly #t and #f) would begin to make sense, 
since scm_is_true would then be useful to replace the 
scm_is_bool/scm_to_bool sequence, similar with scm_is_false. However, I 
can well live with scm_to_bool giving 1 for anything but #f, since even 
in scheme the interpretation of non-#f values as true values is 
standard, and the explicit comparison with #t is comparably seldom.

>What about
>
> scm_from_bool --- return #f for 0, #t for 1, else signal error
>
I would accept any value != 0 as false here. Even when the new ISO-C99 
_Bool type was used, this would still work, since integers will 
implicitly be converted to _Bool, giving 0 for 0, 1 for any non-zero 
value. That is, if we plan to change the argument type to _Bool later, 
signalling an error for values != 0 and != 1 would then become useless 
anyway.

Best regards
Dirk



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