> From: Bruce Korb <bk...@gnu.org>
>>> Which is the higher priority, language purity or ease of use?
>> That is a loaded question, as it presupposes ease of use is always the
>> same thing as impurity e.g. ...
> Absolutely not. Making decisions is always about trade-offs,
> otherwise it is not really a decision. Should you give preference
> to language aesthetics, or preference to ease of use *when*
> there is a divergence? More often than not, language purity
> (consistency) *improves* ease of use. Here we are looking at
> something that does not appear to me to improve ease of use.
> You have to go to some extra trouble to be certain that a string
> value that you have assigned to an SCM is not read only.
> That is not convenience. If Guile were to implement copy on write,
> then the user would not have to care whether a string were
> shared read only or not. It would be easier to use. The only code
> that would care at all would be the Guile internals. (Where it
> belongs -- my completely unhumble opinion :)
Well, I've read all the posts in this thread, and I was pretty aware
of the arguments about read-only strings before this. So since I
have little left to contribute, I'll sign off with one final
statement about it...
I agree completely with Bruce's statement above.
The mutability of strings in Guile 1.8 was a feature, not a weakness.
Even though it wasn't properly implemented, as Mark pointed out, it
did what I meant every time I used it.
I believe that mutability should be the default in all data types.
Creating an immutable compound data type -- be it a string, pair,
vector or whatever -- should never be the default, and should always
be the case that requires extra syntax.
R{5,6,7}RS disagrees with me on that, of course. I think R{5,6,7}RS
is wrong.
I understand the efficiency argument for immutable strings (and pairs).
I don't care, because Guile has never been slow for anything I've asked
it to do.
That, I guess, is my completely unhumble opinion. :)
Regards,
Mike
