Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152

Show/hide message thread

SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 John Cowan (29 Mar 2019 21:17 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 Per Bothner (29 Mar 2019 22:32 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 John Cowan (30 Mar 2019 01:36 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 Per Bothner (31 Mar 2019 01:48 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 John Cowan (31 Mar 2019 19:39 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 Per Bothner (31 Mar 2019 20:24 UTC)

Re: SRFI 13 redux: a proposed compromise between SRFI 140 and SRFI 152 Per Bothner 31 Mar 2019 20:24 UTC

On 3/31/19 12:39 PM, John Cowan wrote:
> Does this mean for example
> that StringBuilder (which does implement CharSequence) would not be an acceptable argument
> to string-set! etc. in Kawa?

That is correct.  Implementing mutable strings using StringBuilder might have made sense,
but there are some downsides (for example string-set! would have required converting the
replacement character to a String).  It would also be possible to overload string-set!
so it also works on StringBuilder, but I have not done so.

> At least one requirement of SRFI 135 is not satisfied by an implementation on top of SRFI 140:
> "There is some reasonably small fixed bound on the ratio of storage used by the shared
> representation divided by the storage that would be used by an unshared representation",
> unless you ensure this by sometimes copying when semantically speaking you could share.
> The bound in question is 16 for the sample implementation of SRFI 135.
The Kawa implementation of substring always shares if the first argument is an IString,
but that should probably be changed.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/