Re: shared-substrings missing in 1.7

[Greg Troxel]

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
:-).

But I see the point of not withdrawing stuff that people depend on.

And I note that make-shared-substring is not flagged as deprecated in
1.6.3, even though Marius says it is:

  http://mail.gnu.org/archive/html/guile-devel/2003-10/msg00027.html

gdt 775 ~ > GUILE_WARN_DEPRECATED=detailed guile
guile> (version)
"1.6.3"
guile> (activate-readline)
guile> (define a "foobar")                     
guile> (define b (make-shared-substring a 0 3))
guile> (string-upcase! b)                      
"FOO"
guile> b
"FOO"
guile> a
"FOObar"
guile> (exit)
gdt 776 ~ > 

(I know GUILE_WARN_DEPRECATED=detailed works since I just hit some
deprecated stuff elsewhere with this same guile binary, such as export
vs re-export and c calls to define functions.)

But, guile.info indeed says it is deprecated:

     Guile Scheme provides the concept of the "shared substring" to
  improve performance of many substring-related operations.  A shared
  substring is an object that mostly behaves just like an ordinary
  substring, except that it actually shares storage space with its parent
  string.

   - Deprecated Scheme Procedure: make-shared-substring str [start [end]]

But, shared substrings are supposed to be immutable (even though they
are not):

     Because creating a shared substring does not require allocating new
  storage from the heap, it is a very fast operation.  However, because it
  shares memory with its parent string, a change to the contents of the
  parent string will implicitly change the contents of its shared
  substrings.

       (string-set! foo 7 #\r)
       bar => "quirk"

     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.)

     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.

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:

  As I've used shared substrings it is also non trivial to
  change the code.

So it sounds like you have code that depends on the cross-mutability
behavior.  It seems that would also break if the COW semantics were
implemented as threatened (with hidden shared substrings).  Does your
code break if you (define make-shared-substring substring)?

-- 
        Greg Troxel <address@hidden>