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,gmane.lisp.guile.user Subject: Re: Worrying development Date: Thu, 22 Jan 2004 17:11:52 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <400FF648.3080706@dirk-herrmanns-seiten.de> References: <1074246064.6729.23.camel@localhost> <87vfn9ufvw.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074788132 18223 80.91.224.253 (22 Jan 2004 16:15:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 16:15:32 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 22 17:15:15 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 1AjhUB-00065M-00 for ; Thu, 22 Jan 2004 17:15:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjhTn-0005Js-8B for guile-devel@m.gmane.org; Thu, 22 Jan 2004 11:14:51 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjhSj-0004tq-1l for guile-devel@gnu.org; Thu, 22 Jan 2004 11:13:45 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AjhSC-0004ef-9x for guile-devel@gnu.org; Thu, 22 Jan 2004 11:13:43 -0500 Original-Received: from [212.227.126.189] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjhRD-0003wd-3O; Thu, 22 Jan 2004 11:12:11 -0500 Original-Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AjhQw-000604-00; Thu, 22 Jan 2004 17:11:54 +0100 Original-Received: from [80.131.44.127] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AjhQw-0002vd-00; Thu, 22 Jan 2004 17:11:54 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <87vfn9ufvw.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.5.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.2 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:3280 gmane.lisp.guile.user:2689 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2689 Hi folks, first, sorry for the late answer... Marius Vollmer wrote: >Roland Orre writes: > > >>I suggest that shared substrings are moved back to guile. >> >> > >Agreed. > >I'm sorry for previously giving the impression that shared substrings >wont come back. > >There is no problem on the Scheme side of things: we can just add >shared substrings and make it a proper subtype of 'string'. > >The problem lies with C code and there only with the low level API >consisting of SCM_STRINGP, SCM_STRING_CHARS etc. Functions like >scm_c_string2str can be updated to just continue to work. > >Shared substrings also touch on the issues of using Unicode in Guile >and on making sure we have a nice type conversion API that can replace >gh_ in all respects. > >I'd like to do it in this order: > > - type conversion API (which allows for different encodings of > strings, but doesn't need it immediately) (the first part of this > was the 'frame' stuff for handling unwinds in C). > > - Unicode (with shared substrings in mind). > > - shared substrings > >Of course, we shouldn't do too much lest 1.8 wont happen... > >I'll try to put forth a proposal in the next days for the string part >of the type conversion API that allows Unicode and shared substrings. > I am not quite sure, everybody is talking about the same issues here: When talking about the re-introduction of shared substrings, Marius, do you think of implicitly shared copy-on-write substrings, or guile's explicitly shared substrings? Shared substrings as they have been provided by guile could have served two purposes: 1) saving resources (run time and memory) 2) communicating changes via something like a shared memory interface The first purpose is just a matter of performance and should not change the functional behaviour of strings. However, guile's former implementation was only imperfectly suited to this kind of usage: Whoever used shared substrings for this purpose needed to be well aware of which strings were actually shared and which were not, because modifications on the strings would cause side effects. Thus, for this purpose the mechanism of implicitly shared copy-on-write substrings is safer. And, this is what we had intended to implement for guile. It would not require the user to perform any explicit action to have substrings to be shared. The second purpose is about a change in behaviour, and to me it is not quite sure that it should be brought back in the old way. Providing shared substrings in that way changes the semantics of strings: Two strings s1 and s2, which are not eq? would become connected in a user-visible way such that modifications to s1 influence s2 and vice versa. What may users of a string data type expect? Shall it be granted that the following expression will always evaluate to true? (if (and (not (eq? s1 s2)) (equal? s1 s3)) (begin (string-set! s2 0 #\x) (equal? s1 s3)) #t) My assumption is that most users will assume the above expression to evaluate to true. If that was not the case, we would require users to perform aliasing checks in their code. Do we really want that? In which way would we extend the string API such that users are able to perform the necessary aliasing checks? IIRC, the old shared substring API did not provide a means for such aliasing checks. The shared substring feature was deprecated since we had considered that feature as a bug in guile's design. I propose not to officially re-introduce it in its former way. The best thing was to have code changed that used the old behaviour. To allow applications to be migrated incrementally, we have provided the feature as deprecated since guile-1.6. If that is not possible for some applications, then a workaround like the one that Mikael and Roland have developed can be used. With that solution, the feature may even remain part of guile - but deprecated, only provided for backwards compatibility! Whoever uses it, should be aware of the fact that due to the aliasing it may lead to problems with other string libraries. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel