From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: GH replacement proposal (includes a bit of Unicode) Date: Thu, 22 Apr 2004 19:36:09 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <40880289.8070405@dirk-herrmanns-seiten.de> References: <4086A1BF.9C8F7914@veritas.com> <87vfjtm2v5.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1082654178 14295 80.91.224.253 (22 Apr 2004 17:16:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2004 17:16:18 +0000 (UTC) Cc: bkorb@veritas.com, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Apr 22 19:15:52 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BGhnk-0003Ru-00 for ; Thu, 22 Apr 2004 19:15:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BGhmj-0003a8-GZ for guile-devel@m.gmane.org; Thu, 22 Apr 2004 13:14:49 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BGhl6-00038t-3R for guile-devel@gnu.org; Thu, 22 Apr 2004 13:13:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BGhkY-00032Q-VX for guile-devel@gnu.org; Thu, 22 Apr 2004 13:13:06 -0400 Original-Received: from [212.227.126.185] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BGhkY-00032G-I4 for guile-devel@gnu.org; Thu, 22 Apr 2004 13:12:34 -0400 Original-Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BGhkV-00026m-00; Thu, 22 Apr 2004 19:12:31 +0200 Original-Received: from [80.131.46.117] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BGhkV-000735-00; Thu, 22 Apr 2004 19:12:31 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <87vfjtm2v5.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3626 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3626 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