From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Worrying development Date: Fri, 23 Jan 2004 14:18:25 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200401232218.OAA27477@morrowfield.regexps.com> References: <1074246064.6729.23.camel@localhost> <87vfn9ufvw.fsf@zagadka.ping.de> <400FF648.3080706@dirk-herrmanns-seiten.de> <200401221842.KAA20956@morrowfield.regexps.com> <40110961.1040808@dirk-herrmanns-seiten.de> <200401231716.JAA26107@morrowfield.regexps.com> <87oesus7kg.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074895769 13502 80.91.224.253 (23 Jan 2004 22:09:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 22:09:29 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jan 23 23:09:18 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 1Ak9UM-00084B-00 for ; Fri, 23 Jan 2004 23:09:18 +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 1Ak9TV-0007Lz-Jq for guile-user@m.gmane.org; Fri, 23 Jan 2004 17:08:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ak9Sn-0007Gz-Io for guile-user@gnu.org; Fri, 23 Jan 2004 17:07:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ak9SG-0006eZ-LJ for guile-user@gnu.org; Fri, 23 Jan 2004 17:07:39 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Ak9SG-0006Os-Cy; Fri, 23 Jan 2004 17:07:08 -0500 Original-Received: from [65.234.195.150] (helo=morrowfield.regexps.com) by mx20.gnu.org with esmtp (Exim 4.24) id 1Ak9QA-0005QC-FN; Fri, 23 Jan 2004 17:04:58 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id OAA27477; Fri, 23 Jan 2004 14:18:25 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: mvo@zagadka.de In-reply-to: <87oesus7kg.fsf@zagadka.ping.de> (message from Marius Vollmer on Fri, 23 Jan 2004 22:01:35 +0100) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2701 gmane.lisp.guile.devel:3296 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2701 > From: Marius Vollmer > Tom Lord writes: > > Mutation-sharing shared substrings are an upwards compatible extension > > to the Scheme standard. They break no correct programs. They enable > > new kinds of programs. > I'd say that the real 'trouble' is that strings are mutable at > all. Worried mostly about variable-length character encodings in string? Or you'd just rather be programming in an ML-family language? :-) If it's variable-length encodings that irk you: if strings were read-only you'd want to optimize the heck out of STRING-APPEND and SUBSTRING and, once you did that, you'd have essentially enough machinery to do mutations efficiently. > Also, I still like the idea of using mutation-sharing substrings as > markers that allow O(1) access into variable-width encoded strings. Interesting. The interaction with STRING-SET! will be tricky. I think you'll either have to "timestamp" strings (one tick per mutation -- and you'll likely have to use a GC'ed value rather than an inline integer for timestamps) or wind up with O(K) for mutations where K is the number of shared substrings. The same problem comes up if you add STRING-RESIZE!. I keep going back and forth on whether or not strings should be the same things as or a subset buffers vs. making buffers a completely separate type. (The latter certainly seems to be easier to implement.) > Also, there is the possibility on the horizon that we turn > string-ref etc into 'primitive generics' which means that people > could implement new kinds of strings using GOOPS. Well, heck. In that case, maybe consider what I'm planning for Pika (at least initially). Purely ASCII strings are stored 1-byte per character. Most other strings 2-bytes per character. Strings using characters outside the Basic Multilingual Plane, 4 bytes per character. You want some fancier-than-libc string functions in C for that -- but it gives you an expected-case O(1) for STRING-REF and STRING-SET! and pretty good space efficiency. It also gives you some performance glitches as when you store a U+0100 character in an otherwise purely ASCII 10MB string. (We're working on providing such fancier-than-libc functions in libhackerlab -- so they'd be available independently of Pika if you went this route.) -t _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user