SRFI 140, Immutable Strings: 150 days
Arthur A. Gleckler
(09 Dec 2016 00:04 UTC)
|
Re: SRFI 140, Immutable Strings: 150 days Per Bothner (09 Dec 2016 00:30 UTC)
|
Re: SRFI 140, Immutable Strings: 150 days
Arthur A. Gleckler
(09 Dec 2016 00:42 UTC)
|
Re: SRFI 140, Immutable Strings: 150 days
Arthur A. Gleckler
(08 Jan 2017 01:56 UTC)
|
Re: SRFI 140, Immutable Strings: 150 days
Per Bothner
(08 Jan 2017 02:20 UTC)
|
Re: SRFI 140, Immutable Strings: 150 days Per Bothner 09 Dec 2016 00:29 UTC
On 12/08/2016 04:03 PM, Arthur A. Gleckler wrote: > This is a reminder that SRFI 140, Immutable Strings, has > been under public discussion for over 150 days. (It was > first published on 2016/7/11.) In theory, the longest > extension was supposed to have been to ninety days. > > Per, would you please reply publicly with a brief update on > the status of the SRFI? Should it be withdrawn, or would > you like to continue revising it? I'm actually working on a related matter right now, with the intent of sending a status update soon. What I have been working on is a test implementation in the context of the "invoke" development branch of Kawa. What I have is: * an efficient implementation of O(1)-indexable immutable string (the class gnu.lists.IString) (My plan is to also offer a portable implementation on top of SRFI-135's text implementation.) * Scheme literal strings are now gnu.lists.IString rather than the "native" java.lang.String. (This broke a lot of stuff.) * Procedures with read-only string parameters work for both mutable and immutable strings (or more generally any value that implements the standard interface java.lang.CharSequence). * Tweaked the conversions between the various types of strings. * Switchable implementation of string-append: It returns an immutable IString by default or if you import (kawa base); it returns a mutable FString if you import (scheme base) or specify the --r7rs command-line flag. Of course string-append is just the beginning, but it provides a test of the complications dealing with compatibility and switchable standards-compliance. The rest of the functions should be comparatively trivial to deal with (except maybe substring, if we want it to do sharing). This now basically working but it led me into a tedious but desirable re-write of how the builtin environment is set up. Once I've got that checked in, I'll send an invitation (to both this list and the Kawa list) to try the invoke branch on your code, before continuing with the other procedures. So far, very little plain Scheme code has broken, but I've had to fix a lot of little things in the implementation, partly because Kawa is more strongly typed than most Schemes, and partly because of the integration with the Java platform. -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/