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: Thu, 03 Jun 2004 23:40:03 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87smdcqq18.fsf@zagadka.ping.de> References: <40812F4B.3080700@dirk-herrmanns-seiten.de> <873c65be76.fsf@zagadka.ping.de> <40A5E7C8.9080409@dirk-herrmanns-seiten.de> <87isel64mf.fsf@zagadka.ping.de> <40B50BA8.2050604@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 1086298835 18057 80.91.224.253 (3 Jun 2004 21:40:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Jun 2004 21:40:35 +0000 (UTC) Cc: Paul Jarc , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jun 03 23:40:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BVzwm-0008Ep-00 for ; Thu, 03 Jun 2004 23:40:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVzx8-0002z2-0b for guile-devel@m.gmane.org; Thu, 03 Jun 2004 17:40:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BVzx0-0002yM-Rp for guile-devel@gnu.org; Thu, 03 Jun 2004 17:40:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BVzwz-0002xc-Ud for guile-devel@gnu.org; Thu, 03 Jun 2004 17:40:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVzwz-0002xS-SW for guile-devel@gnu.org; Thu, 03 Jun 2004 17:40:37 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BVzwV-0007nd-Q6 for guile-devel@gnu.org; Thu, 03 Jun 2004 17:40:08 -0400 Original-Received: from dialin.speedway15.dip93.dokom.de ([195.253.15.93] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BVzzW-000081-00 for guile-devel@gnu.org; Thu, 03 Jun 2004 23:43:15 +0200 Original-Received: (qmail 13986 invoked by uid 1000); 3 Jun 2004 21:40:03 -0000 Original-To: Dirk Herrmann In-Reply-To: <40B50BA8.2050604@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Wed, 26 May 2004 23:27:04 +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:3779 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3779 Dirk Herrmann writes: > Marius Vollmer wrote: > >> Dirk Herrmann writes: >> >> > Marius Vollmer wrote: >> > >> >> Hmm, yes, that might make sense. However, the -1 idiom is pretty >> >> much standard for this kind of interface, no? >> > >> > I personally don't like this kind of 'one value, several meanings' >> > paradigm: >> > >> > - What, if instead of -1, you pass -2? [...] - Readability suffers. >> > [...] >> >> Yes, I agree that the -1 idiom is not self explaining, but it is well >> established and people will instantly recognize it. I'd even argue >> > What about the -2 and so on? The way it is worded in the proposal right now, -2 would be interpreted as an unsigned value, that is, as a very large length. In other words, only one value, ((size_t)-1), is interpreted specially. > You are trying to explain why the -1 idiom is not too bad. I'm arguing that it is well known, not that it is necessarily good or better. Also, I really do think that people expect to be able to pass -1 as the length parameter, as a convenience feature. One point of the proposal is to make the API very easy to use, where the 'obvious' way to use it is also the correct one. So, IMO, we need to interpret -1 specially. The question is then, is it an advantage to have an additional way to have Guile count the string length on its own? > But, why do you think it is better? I think it is good enough, but I'm of course listening to your arguments. >> established and people will instantly recognize it. I'd even argue >> that they will expect to be able to pass -1 for a 'len' parameter and >> will be annoyed when they find out that Guile doesn't allow it. > > That's a guess. Maybe you should ask the people what they would prefer? > Considering me as part of them, I would not prefer having the -1 idiom. Noted. > Summarized, I would just claim that it is not a good API design, > since I have not yet seen a convincing argument in favor of it. Yeah, I'm convinced. > Considering your and Paul's answer, I would like to change my suggestion > to the following pair of functions: > > SCM scm_from_locale_string (const unsigned char *str, size_t len); > SCM scm_from_locale_0string (const unsigned char *str); I would not like to use the "memory" term to indicate a string that is not zero terminated; "memory" is too generic. Also, "0string" feels not right either, since it makes it look as if a 0string would be something very special although it is the ordinary thing (for C). What about SCM scm_from_locale_string (unsigned char *str); SCM scm_from_locale_string_counted (unsigned char *str, size_t len); 'scm_from_locale_string_counted' would treat len == -1 specially. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel