[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dirk Herrmann
Subject: Re: GH replacement proposal (includes a bit of Unicode)
Date: Thu, 22 Apr 2004 19:36:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]