From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Internal visibility Date: Mon, 02 Jun 2008 00:02:46 +0200 Message-ID: <87wsl8eruh.fsf@gnu.org> References: <87k5i5d6ei.fsf@ossau.uklinux.net> <87lk2jhp0h.fsf@gnu.org> <87skwrce8y.fsf@ossau.uklinux.net> <87iqxledzz.fsf@gnu.org> <87lk2futg0.fsf@ossau.uklinux.net> <87fxslr1jr.fsf_-_@gnu.org> <878wxv5t7q.fsf@gnu.org> <87mym6dv6t.fsf@gnu.org> <49dd78620806010100i6fe37521q249e973bd25d81c3@mail.gmail.com> <87prr1l8jf.fsf@gnu.org> <49dd78620806011348w400a75c5xaea1af79f9b94949@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1212357820 20460 80.91.229.12 (1 Jun 2008 22:03:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2008 22:03:40 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 02 00:04:21 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K2vf2-0005Vz-4i for guile-devel@m.gmane.org; Mon, 02 Jun 2008 00:04:20 +0200 Original-Received: from localhost ([127.0.0.1]:59519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2veG-0000xI-5q for guile-devel@m.gmane.org; Sun, 01 Jun 2008 18:03:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K2vdn-0000Xu-L4 for guile-devel@gnu.org; Sun, 01 Jun 2008 18:03:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K2vdm-0000WF-0G for guile-devel@gnu.org; Sun, 01 Jun 2008 18:03:03 -0400 Original-Received: from [199.232.76.173] (port=33333 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2vdl-0000W3-U9 for guile-devel@gnu.org; Sun, 01 Jun 2008 18:03:01 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:57256 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K2vdl-0004I4-Gv for guile-devel@gnu.org; Sun, 01 Jun 2008 18:03:01 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K2vdf-0002PZ-Rt for guile-devel@gnu.org; Sun, 01 Jun 2008 22:02:55 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jun 2008 22:02:55 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jun 2008 22:02:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 28 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 14 Prairial an 216 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:Bt5mfWYsPRFjuI8AkpvHsJIY43A= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7298 Archived-At: Hi, "Neil Jerram" writes: > 2008/6/1 Ludovic Courtès : >> >> It's just that it's convenient and equivalent to 1.6's `SCM_STRING_CHARS ()', >> so people have come to use it... According to Google's codesearch, >> `scm_i_string_chars ()' is used by Mailutils, Lilypond, AutoGen, SND and >> a few others. > > IMO that amounts to a strong case for making it an official API. I > believe the argument against doing that is something to do with future > multi- and variable-byte string encodings - but perhaps we can handle > that as a transitional issue once those encodings are in place? I did not mark them as internal so as to leave them in this "semi-official" state. But it was always clear from 1.8.0 that the `i' in `scm_i_' means "internal" and that applications could only use it at their own risk, so I wouldn't want to go as far as documenting or encouraging it. As Clinton said, there were good reasons for these functions to be internal in the first place, and it seems more reasonable to keep it this way. We *will* support Unicode eventually, right? :-) Thanks, Ludovic.