making up language features

[Tom Lord]

The discussion on strings threatens to spiral into a kind of noise
that people use to kill projects.

The discussion now has nose dived into unmotivated, out-of-the-blue
"what ifs".  What if I pass an immutable string to a hypothetical
string-mutating procedure?  [I'd say you screwed up.]  Should
copy-on-write be automatic for some kinds of string?  [I'd say the
difficulties of either preserving or losing eq? identity of the
copy-on-write string point out that your question comes from a
confused perspective.  Think it through more before proposing the idea
again.]  What if my (hypothetical) mail reading program doesn't work
correctly when someone calls one of its procedures incorrectly?  [I'd
say, "Yeah, so?  Procedures _usually_ don't work when called
incorrectly."]

So how ought language design decisions be made for Guile?  Is it just
``Whatever faction gets tired first looses?''  or ``Whoever checks in
code the fastest wins?''  How has that worked so far?

Once again, I think some good directions for the project would be:

        - Freeze new features and work on testing, performance,
          and robustness.  With tools to thoroughly measure the
          state of the implementation, further development will
          go more smoothly and produce more reliable results.

        - Pick an application to build Emacs-style -- using the
          extension language as the primary implementation language,
          and make that application work well.

        - Clean up the build/install process to eliminate automake
          and autoconf.

        - Pick up some of the features that have worked well in
          Systas.

I think the original goal of making a powerful extension language
remains a good one.  I suspect that Guile needs some huge changes
before that goal can be achieved, but perhaps there are some small
clever changes that will have the same effect.  Regardless, more
attention to testing and measurement would be a first step in the
right direction and a benefit to either approach.

About the string features I favor:

I've written some fairly complex, moderately sized applications with
Systas Scheme in order to get Real Work done.  It was in that context
that I decided read-only strings are a good feature.  It turns out to
be natural to avoid passing read-only strings to procedures that
mutate strings -- little or no special effort is required.  It's no
more difficult than using a mutable string but relying on the fact
that it won't, in fact, be modified.  It turns out that being able to
pass symbols to non-mutating string procedures is convenient and cheap
to implement.  That's my experience.

Also, R5RS (if you're into that sort of thing) allows for unmutable
strings and doesn't provide any predicate to test for them.

-t