From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: GH replacement proposal (includes a bit of Unicode) Date: Mon, 24 May 2004 21:36:07 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87ekp962jc.fsf@zagadka.ping.de> References: <40812F4B.3080700@dirk-herrmanns-seiten.de> <873c65be76.fsf@zagadka.ping.de> <40A5EE69.8020200@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085434421 30319 80.91.224.253 (24 May 2004 21:33:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 May 2004 21:33:41 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 24 23:33:32 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 1BSN4d-00021L-00 for ; Mon, 24 May 2004 23:33:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BSMAG-0003Y9-Ah for guile-devel@m.gmane.org; Mon, 24 May 2004 16:35:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BSM9z-0003Wc-Vh for guile-devel@gnu.org; Mon, 24 May 2004 16:35:00 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BSLgE-0007HR-Bf for guile-devel@gnu.org; Mon, 24 May 2004 16:04:45 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BSLF7-0002V0-VH for guile-devel@gnu.org; Mon, 24 May 2004 15:36:14 -0400 Original-Received: from [195.138.44.29] (helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BSLHx-0002vx-00 for guile-devel@gnu.org; Mon, 24 May 2004 21:39:09 +0200 Original-Received: (qmail 11166 invoked by uid 1000); 24 May 2004 19:36:07 -0000 Original-To: Dirk Herrmann In-Reply-To: <40A5EE69.8020200@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 15 May 2004 12:18:17 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) 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:3752 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3752 Dirk Herrmann writes: >> Yes, but I don't want to worry about this yet, since I really think >> this kind of range checking will not be done significantly often. > > I doubt that this is true. The only scenario, where I would _not_ perform > this kind of check is, when I have the full control over all the code that > generates the numbers, and when I know my algorithms well enough to > know that no overflow can occur. > > In all other cases, I would at least prefer to print out a warning, at which > place I have received incorrect value. For example, if the number comes from > some extension code provided by the user of my application: It is good > style to indicate clearly, what the user's code did wrong. That is, whether > or not you can do something about a bad value, you still want to know it, > at least to be a little bit more user friendly in your error messages. Hmm, there might be a misunderstanding somewhere: they way I want it, scm_to_int would either produce a correctly converted 'int', or would signal an error. The error might be a 'wrong type argument' one when a non-integer has been passed to scm_to_int, or it might be a 'argument out of range' one, when the integer doesn't fit into an 'int'. There would not be the case that code would silently work with incorrect values. Given this behavior, I still think that explicitely checking whether a SCM value fits into a 'int' will not be done often. When the value doesn't fit, what do you do? You could print a warning, but wouldn't the error produced by scm_to_int be better? You could try to explicitly deal with non-int values, but how? When you have a method to deal with non-ints why not use it always? Maybe it is much less efficient, so there really is a reason to do range checks. But I believe that this situation happens both infrequently and when it happens, the second done by scm_to_int is not a problem. When it really is a problem, tho, it is likely worthwhile to use the internal stuff of libguile directly, such as SCM_INUMP, SCM_MAKINUM, SCM_INUM, etc. This will be less portable across versions of Guile, of course, but when that is what it takes... I see the typical use of scm_to_int etc to be in glue code, like SCM posix_kill (SCM pid, SCM sig) { return scm_from_int (kill (scm_to_int (pid), scm_to_int (sig))); } That is all it should take to wrap 'kill'. >> >> - SCM scm_from_complex_double (double re, double im); - double >> >> scm_to_real_part_double (SCM z); - double scm_to_imag_part_double >> >> (SCM z); [...] >> > >> > We should be prepared to provide conversion functions for the new >> > ISO-C99 types float _Complex, double _Complex, long double >> > _Complex, float _Imaginary, double _Imaginary and long double >> > _Imaginary. Thus, the naming scheme used above seems a bit >> > confusing if we later expect a function scm_from_double_complex to >> > be added. >> >> Hmm, tough. What about removing scm_from_complex_double completely >> and tell people to use >> >> scm_make_rectangular (scm_from_double (r), scm_from_double (i)) >> >> instead? The scm_from_double_r_double_i scheme looks a bit too >> complicated to me. > > No problem with that. Let's just wait if there is lot of demand for > something > more efficient, we can re-think the issue then. Yes. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel