Re: string-map arg order

[Dirk Herrmann]

On 5 Sep 2001, Alex Shinn wrote:

> >>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
> 
>     Dirk> Resizing is an option if you make sure that no memory region
>     Dirk> that is being used gets freed.  That's the reason why I
>     Dirk> introduced the separation of a memory-region object and the
>     Dirk> string objects that use it.  See
>     Dirk> http://mail.gnu.org/pipermail/guile-devel/2000-November/000586.html
> 
> Hmmm.... this is a pretty big change in the way people will have to
> handle strings.  We could deprecate SCM_STRING_CHARS and redefine it
> as something like
> 
> #define SCM_STRING_CHARS(x) SCM_STRING_CONTENT_CHARS(SCMS_STRING_CONTENT(x))
> 
> but this wouldn't always work in threaded situations.  As your code
> points out, every function that accepts a string will have to save the
> content and use scm_remember_upto_here().  On the other hand, this is
> only going to be a problem if people want to use both multi-byte
> characters, string mutation, and threading in the same app.

Well, it actually suffices to use string mutation with any string
implementation that that does some form of copy-on-write:  multi-byte
characters, fixed width encoded strings that do not start with the maximum
width by default and shared substrings all come to mind here.  Threading
is not even necessary, see the example below...

> Note that we can also use this same approach when resizing utf8
> strings, so we can get back the O(n) time on string-for-each and kin.
> Thanks for pointing that out :)

Sorry, no :-)  Look at the following pseudo code that runs in a
single-threaded guile and tell me how you would implement string-for-each
in O(n) with a multi byte encoding...

  (define s <some string>)
  (define (foo c)
    (string-set! s (random-index (length s)) (random-character)))
  (string-for-each foo s)

Don't tell me this is ugly :-)

Best regards
Dirk Herrmann