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: Wed, 12 May 2004 22:09:01 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <873c65be76.fsf@zagadka.ping.de> References: <40812F4B.3080700@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 1084393434 12785 80.91.224.253 (12 May 2004 20:23:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 20:23:54 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 12 22:23:43 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 1BO0GU-0002To-00 for ; Wed, 12 May 2004 22:23:42 +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 1BO0EB-0000mx-VG for guile-devel@m.gmane.org; Wed, 12 May 2004 16:21:20 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BO06V-0007aq-RZ for guile-devel@gnu.org; Wed, 12 May 2004 16:13:24 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BO04r-0006t5-6T for guile-devel@gnu.org; Wed, 12 May 2004 16:12:13 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BO02N-0005oD-HL for guile-devel@gnu.org; Wed, 12 May 2004 16:09:08 -0400 Original-Received: from dialin.speedway43.dip52.dokom.de ([195.138.43.52] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BO051-0005b4-00 for guile-devel@gnu.org; Wed, 12 May 2004 22:11:51 +0200 Original-Received: (qmail 8475 invoked by uid 1000); 12 May 2004 20:09:01 -0000 Original-To: Dirk Herrmann In-Reply-To: <40812F4B.3080700@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 17 Apr 2004 15:21:15 +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:3707 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3707 Dirk Herrmann writes: >> - scm_t_intmax scm_to_signed_integer (SCM val, >> scm_t_intmax min, scm_t_intmax max); >> - scm_t_uintmax scm_to_unsigned_integer (SCM val, scm_t_uintmax max); >> > Since ISO-C99 specifies the intmax_t and uintmax_t typedefs, I would > prefer to have functions scm_to_intmax and scm_to_uintmax, and have > them behave similarly to scm_to_int etc. which you describe > below. We should have them, but in addition to scm_to_signed_integer and scm_to_unsigned_integer. The latter two functions should be the most general ones that the use can use to easily convert integer types that are not specifically covered by Guile. For example, glib provides a type gint with limits G_MININT and G_MAXINT. To convert to this type, you could do (gint)scm_to_signed_integer (val, G_MININT, G_MAXINT) > In addition, it may make sense to use the generic type names signed > integer and unsigned integer to provide additional functions > scm_to_signed_integer and scm_to_unsigned_integer that implement the > very general conversion idea that Gary Houston had proposed in > http://mail.gnu.org/archive/html/guile-devel/2001-09/msg00290.html. I like this idea, but I think we should provide it in an even more general form, converting integers to uniform vectors with a given word size and endianess. Using intmax_t should be good enough for all ordinary integer conversion needs, and much less hairy. > 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); > 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. >> - 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. >> - SCM scm_from_locale_string (unsigned char *str, ssize_t len); >> >> Return a new Scheme string initialized with STR, a string encoded >> according to the current locale. When LEN is -1, STR must be >> zero-terminated and its length is found that way. Otherwise LEN >> gives the length of STR. >> > I would prefer to have two functions like scm_from_locale_memory (with > an unsigned len argument) and scm_from_locale_c_string rather than > using -1 as a magic number. The same holds for the other > scm_from_ functions that you describe below. Hmm, yes, that might make sense. However, the -1 idiom is pretty much standard for this kind of interface, no? >> - unsigned char *scm_to_locale_string (SCM str, size_t *lenp); >> >> Convert STR into a C string that is encoded as specified by the >> current locale. Memory is allocated for the C string that can be >> freed with 'free'. >> >> When the current locale can not encode STR, an error is signalled. >> >> When LENP is not NULL, the number of bytes contained in the returned >> string is stored in *LENP. The string is zero-terminated, but it >> might contain zero characters in the middle. >> > Is the terminal zero counted or not? No, as usual. >> - scm_lock_heap (); >> - scm_unlock_heap (); >> > I urgently suggest that we do not provide such a concept. It makes too > many implementation details visible to the user (the way, strings are > implemented internally) and has influences on critical system parts > (memory management). It is not foreseeable in which way this may > inhibit further development. From my work on the evaluator I can tell > you how much leaked implementation details inhibit improvements. Yeah. I will withhold this part of the proposal until I have made my mind up more. I would only be implemented (for strings) anyway when we have Unicode support, since only then could scm_l_get_utf8_string_mem be implemented. -- 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