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: Tue, 13 Apr 2004 15:25:53 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081865437 11470 80.91.224.253 (13 Apr 2004 14:10:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2004 14:10:37 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 13 16:10:28 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 1BDOcO-0006kW-00 for ; Tue, 13 Apr 2004 16:10:28 +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 1BDOBn-0000UX-A7 for guile-devel@m.gmane.org; Tue, 13 Apr 2004 09:42:59 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDO91-0008Mq-1v for guile-devel@gnu.org; Tue, 13 Apr 2004 09:40:07 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDO8P-0008CA-So for guile-devel@gnu.org; Tue, 13 Apr 2004 09:40:01 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDNvJ-0003Q4-GG for guile-devel@gnu.org; Tue, 13 Apr 2004 09:25:57 -0400 Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id A55972400D for ; Tue, 13 Apr 2004 15:25:54 +0200 (CEST) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id C2258B99F; Tue, 13 Apr 2004 15:25:53 +0200 (CEST) Original-To: guile-devel@gnu.org In-Reply-To: (Paul Jarc's message of "Wed, 07 Apr 2004 11:04:47 -0400") User-Agent: Gnus/5.1003 (Gnus v5.10.3) 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:3595 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3595 prj@po.cwru.edu (Paul Jarc) writes: > Marius Vollmer wrote: >> I have a partial proposal for making type conversions between Scheme >> and C easier. > > Looks nice & clean. Thanks, do you think it worth implementing (and thereby deprecting the old stuff)? >> - macro-free so that we can maintain binary compatibility easier > > Well, macros don't cause problems as long as the underlying functions > (if any) also keep the same interface, right? Has there been much > change of, or pressure to change, those interfaces with the current > macros? I agree that this is not the most important point: there wont be binary compatability between 1.6 and 1.8 anyway. But of course, it would be nice to have easier binary compatability in the future. >> Then there is the error handling: the functions below do not take >> "subr" or "pos" arguments to indicate where the error has happened. I >> don't think they are really needed and in any case only provides part >> of the backtrace. > > I have some code that benefits from having the subr name in the > exception - in the case of 'system-error, it walks the stack to find > and report the call that failed, including arguments. Can you give a quick example? (Does it walk the C stack and prints the failed system call?) >> * Conversion from Scheme to C >> >> scm_to_ (SCM val, ...); >> >> ("convert Scheme to ".) When VAL is not representable as a >> or additional constraints are not satisfied, an error is >> signalled. > ... >> - int scm_to_bool (SCM); >> - int scm_is_true (SCM); >> >> Return 0 when SCM is SCM_BOOL_F, else return 1. > > That sounds good for scm_is_true, but maybe scm_to_bool should throw > an exception if given a value other than SCM_BOOL_[TF], for > consistency with other scm_to_* functions. Hmm, I don't think we should do that. There is nothing to be gained in treating SCM_BOOL_T specifically here. Everywhere else, all values except SCM_BOOL_F are true, so why should we force the explicit use of SCM_BOOL_T with scm_to_bool? Maybe we should't have scm_to_bool and scm_is_bool at all? scm_is_true (and maybe scm_is_false) should suffice. >> - SCM scm_is_bool (SCM val); > ... >> - SCM scm_is_integer (SCM val); > > Those should return int, right? Yes, thanks! >> - 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); > > Wouldn't a min parameter sometimes be useful for unsigned values too? Yes, maybe. I'll add it. >> - long scm_to_unicode (SCM ch); >> - SCM scm_from_unicode (long code); > > long, or unsigned long? Does Unicode need negative values? No, Unicode does not need negative values (as far as I know). I'll make this unsigned. >> - 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. > > Maybe it doesn't matter much, but len could be size_t, and (size_t)-1 > could be the only special value, instead of losing a whole bit to > signedness. It doensn't matter much, there wont likely ever be support for strings that are longer than 31 bits worth of length (or 63 bits). Right now, strings have only 24 bits for their length (or 56 bits). But yes, we shouldn't restrict us in the interface, so I'll change LEN to size_t. We should also specify the units of LEN... >> The heap should not be locked for long periods of time and no >> calls to 'normal' libguile functions are allowed while it is >> locked. > > What happens if one is called anyway? Exception, or undefined > behavior? Undefined behavior. The function will likely try to lock/unlock the heap again and that might crash or unlock the heap too early, etc... >> - SCM scm_c_list_ref (SCM list, int idx); >> - SCM scm_c_list_set (SCM list, int idx, SCM val); >> - int scm_c_list_length (SCM list); > > I'd suggest size_t instead of int. Same for vectors. Yes, much better. Thanks! _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel