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: Sat, 15 May 2004 12:18:17 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <40A5EE69.8020200@dirk-herrmanns-seiten.de> References: <40812F4B.3080700@dirk-herrmanns-seiten.de> <873c65be76.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 1084614903 25510 80.91.224.253 (15 May 2004 09:55:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 09:55:03 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 15 11:54:53 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 1BOvsb-0005Jg-00 for ; Sat, 15 May 2004 11:54:53 +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 1BOvqN-0005FC-UP for guile-devel@m.gmane.org; Sat, 15 May 2004 05:52:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOvq3-00057L-Vb for guile-devel@gnu.org; Sat, 15 May 2004 05:52:16 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOvpV-0004eR-5J for guile-devel@gnu.org; Sat, 15 May 2004 05:52:12 -0400 Original-Received: from [212.227.126.176] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOvpU-0004eG-KI for guile-devel@gnu.org; Sat, 15 May 2004 05:51:41 -0400 Original-Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BOvpU-0005ro-00 for guile-devel@gnu.org; Sat, 15 May 2004 11:51:40 +0200 Original-Received: from [80.131.38.93] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BOvpT-0006ss-00; Sat, 15 May 2004 11:51:39 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040220 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <873c65be76.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.8.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:3717 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3717 Marius Vollmer wrote: > Dirk Herrmann writes: > > > Alternative 1: * change the functions in the following way: > > scm_to_ (SCM value, int *success) Instead of signalling an > > error, *success indicates whether the value can be represented. If > > *success is 0, the returned value is unspecified. If success is > > NULL, an error is signalled for the case that the value can not be > > represented. > > I don't like this very much; I want the fundamental functions to be > as simple as possible. Passing NULL or (worse), having to pass a > valid pointer add significant noise to the code, and I would like to > avoid this. > > > Alternative 2: * provide the following additional functions: > > scm_to__2 (SCM value, int *success) I have not yet an idea > > for a good name, thus I have just added the _2 postfix. Alternative > > 3: * provide the following additional functions: int > > scm_fits_ (SCM value); Return 1 if the value can be converted > > to a C value of type , 0 otherwise. If scm_fits_ > > returns 1 for some value it is guaranteed, that a subsequent call > > to scm_to_ does not signal an error. > > In my opinion, keeping type tests and type conversions separate is > the cleanest approach. Testing whether an integer fits a given C > type should be quite seldom: what do you do when it doesn't fit? > > So, I like alternative 3 best; and I think it will suffice to provide > only two functions: > > int scm_is_unsigned_integer (SCM val, scm_t_uintmax min, > scm_t_uintmax max); > > int scm_is_signed_integer (SCM val, scm_t_intmax min, scm_t_intmax > max); Yes, when choosing alternative 3, this would be a nice solution. It might also make sense to add these functions if one of the other alternatives would be chosen. > > The disadvantage of alternative 3 is, that for a lot of code the > > checking will have to be performed twice: The user will first call > > scm_fits_ and then scm_to_. Both, however, will check > > whether the value fits. > > 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. And, as I had clarified in a later mail: DH>> I would even go further and simply disallow the passing of NULL. It's DH>> just another asymmetry and magic number. The rule woule be, that (if DH>> the SCM argument is of the correct type), the caller always has to DH>> provide a valid pointer for success. On the contrary, if the SCM argument DH>> is not of the correct type, an error should be thrown. The success DH>> argument is therefore only for overflow checks, not for type checks. DH>> This is symmetric with the other conversion functions. It may be that we end up with different opinions here. That's OK, but for the final decision I suggest to check what after the discussion the majority of developers (or users) prefers. > >> - 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. Best regards, Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel