Re: shared-substrings missing in 1.7

[Tom Lord]

    > From: Greg Troxel <address@hidden>

    > This is a guile-specific non-R5RS feature, AFAICT.  It seems a bit
    > non-Schemely, too, for a mutation of one object to cause another to
    > change (exercise for the reader: write denotational semantics for this
    > :-).

Why is that significantly different from a mutation of one list
changing another?

        (define x (list 'b 'c 'd))
        (define y (cons 'a x))


        y => (a b c d)

        (set-car! x 'semantics-schmemantics)

        y => (a semantics-schmemantics c d)

Specifying the semantics of mutation-effects-both shared substrings is
as easy as specifying the semantics of cons pairs.



    > But, shared substrings are supposed to be immutable 

Ideally there would be two kinds of shared substring: copy-on-write
and mutation-effects-both.   MAKE-SHARED-SUBSTRING would create a
mutation-effects-both shared substring;  SUBSTRING could create a
copy-on-write shared substring.   MAKE-COW-SUBSTRING could have the
same meaning as SUBSTRING but provide a distinct hint to the
implementation about how the string is expected to be used.


    >      Guile considers shared substrings to be immutable.  This is because
    >   programmers might not always be aware that a given string is really a
    >   shared substring, and might innocently try to mutate it without
    >   realizing that the change would affect its parent string.  (We are
    >   currently considering a "copy-on-write" strategy that would permit
    >   modifying shared substrings without affecting the parent string.)

That's all fine but when a programmer knows what she is doing, a
mutation-effects-both string is potentially exactly what is wanted.

How about something like:

        (string-downcase! (make-shared-substring from:-line
                                                 hostname-start 
                                                 hostname-end))

to turn:

        "Greg Troxel" <address@hidden>

into 

        "Greg Troxel" <address@hidden>

The equivalent-performance alternative there is to make
STRING-DOWNCASE! and all similar functions accept optional START/END
parameters -- a solution that quickly gets quite out of hand.


    >      In general, shared substrings are useful in circumstances where it is
    >   important to divide a string into smaller portions, but you do not
    >   expect to change the contents of any of the strings involved.

Not "In general" but "In some cases".


    > So even though I really don't like backwards-incompat changes, it
    > seems that removing them is reasonable, and that you are having
    > trouble because you are relying on undefined behavior:

It didn't start out as undefined.  When first added,
MAKE-SHARED-SUBSTRING returned a mutation-effects-both substring.
It was a feature.

-t