Re: Worrying development

[Tom Lord <lord@emf.net>]

    > From: Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>

    > As you say, the standard only describes functions that, on creation of 
    > strings, requires to allocate fresh locations for the contents of the 
    > strings. That is, someone who only uses the functions that are described 
    > by the standard is not able to create any mutation-sharing substring. 
    > And this, implicitly, indicates that different (in the sense of eq?) 
    > strings use different locations for their contents. To me this seems 
    > like a valid assumption. 

It's subtly wrong.

A program (or, more importantly, a module) can assume that non-eq?
strings are disjoint in their storage _if_and_only_if_ either (1) it
knows how both strings were created or (2) it's
assumption-of-disjointness is shared with the caller who passes the
strings to the module.

(1) is trivially obvious.

(2) may sound onerous but it really isn't.  It falls out of the
    existing practice of procedures advertising clearly what arguments
    they mutate.  A caller passing around mutation-sharing strings has
    to be careful to pass them to mutating procedures only when they
    are certain that they want mutations to be shared.   Ultimately,
    that obligation propogates right back to the point of creation of
    the mutation-sharing substring --- using mutation-sharing
    substrings is, every step of the way, a perfectly localized (a
    perfectly "modular") decision.

    You keep worrying about what happens if a procedure mutates a
    string and then is "surprised" when that mutation effects some
    other string.   No procedure need worry about that -- it is
    entirely up to code which _creates_ a mutation-sharing string to
    only pass it to a mutating procedure when it knows what it's doing.

    > Standard-conforming scheme programs may IMO 
    > rely on this fact [that non-eq? strings can't possibly share
    > mutations]

Freestanding portable standard programs can rely on that fact -- and
adding mutation-sharing substrings doesn't change that in the
slightest.

Modules, intended to be combined with other modules that may be using
non-standard feature can _not_ rely on that fact and have never been able
to rely on that fact.   Mutation-sharing substrings drive that point
home but they aren't the only reason.

But that property of modules is not really a problem in practice.
You have to have a pretty twisted Scheme programming style to run into
a case where it will make a difference.

    > >Mutation-sharing shared substrings are an upwards compatible extension
    > >to the Scheme standard.  They break no correct programs.  They enable
    > >new kinds of programs.

    > Introducing a separate data type for mutation-sharing character arrays 
    > also enables new kinds of programs. The difference between a separate 
    > data type and the former implementation is, that mutation-sharing 
    > substrings could be used everywhere where an ordinary string had been 
    > used before. That is, the difference is a matter of being able to re-use 
    > existing string-handling code rather than enabling new kinds of 
    > programs. However, it is exactly this re-using of existing 
    > string-handling code issue which becomes problematic when the semantics 
    > of the string objects change.

I don't believe that it's problematic in the slightest.   Certainly no
more so than re-using a standard Scheme module in a multi-threaded Scheme.

    > Marius, would it be an acceptable compromise to require that the 
    > mutation-sharing substring issue be submitted and discussed as an srfi 
    > before it becomes an official part of guile's core? The discussion of 
    > the topic in that forum would reduce the risk that the change introduces 
    > problems. I would then ask those who are interested to have it as a part 
    > of guile to submit a srfi proposal.

    > (Please note that, as I have said before, I have nothing against 
    > providing mutation-sharing substrings as a deprecated feature for some 
    > period - but not as an official part of guile's core.)

I guess what really bugs me about the issue is that the feature was
(semi-) removed based on pure speculation, opinion, and apparently by
imperfect interpretation of the standard.   I don't think that there
was a record of the feature causing any serious and sustained
problems.   It's removal seemed rather a rather gratuitous snub.

-t



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user