Re: Issue "Eliminate forced consing" re-visited

[Scott.Fahlman@B.GP.CS.CMU.EDU]

Let me repeat and amplify the response I made to this proposal when it
first came out.

The destructive versions of the various sequence functions are rather
dangerous to use, and are the source of confusing and hard-to-find bugs in
code written by people who don't appreciate these dangers.  On the other
hand, we are trying to produce and industrial-strength language here, and
we must provide users with SOME way to do non-consing operations on
sequences.  The presence of DELETE in the language shows that were are
willing to accept the added complexity and danger when the only other
choice is inefficiency.  The question is not whether the language should
allow efficient, non-consing sequence operations, but how we can best
package them to reduce the danger.

At present, the principal alternative to using CONS-intensive sequence
functions is to write your own loops in an iterative style.  Unfortunately,
we have poor tools for iterative programming.  I was not at the recent
meeting, but I believe that the iteration committee is now functioning and
plans to propose a version of the LOOP macro as an addition to the
standard.  If this comes to pass, I believe that the sequence functions
will end up being used only for the simplest kinds of loops -- a
kind of shorthand that makes the programmer's intention clear in the most
common cases -- and that the more complex options in the sequence functions
will tend to atrophy from disuse.  If that is right, then it makes little
sense to add another layer of complexity to these things, just at the time
when we are providing a decent alternative in the LOOP facility.

I find that even without the LOOP facility, I tend to use the sequence
functions only in simple ways, and move over to a DO loop if the situation
becomes at all complex.  The positive side of this is that I make fewer
mistakes in coding, because I'm telling the program exactly what I want it
to do rather than guessing what the sequence function would do.  With
sequence functions, it is easier to see at a glance what the programmer is
trying to do, but harder to tell if he's doing it exactly right.  I'm not
sure if others share this preference, however.

So I believe it comes down to two questions:

1. Do we really believe that LOOP or something very close to it will be
adopted in the near future?

2. Do we believe that if the LOOP facility were part of the standard, it
would provide a better way of writing complex, non-consing loops than would
be provided by the sequence functions augmented with :TARGET or whatever?

If the answer to both questions is yes, then it makes no sense to put in
this target stuff right now.  Were it not for the problem of breaking
existing code, we might even want to eliminate some of the more complex
options from the existing sequence functions.  On the other hand, if the
answer to either question is no, then :TARGET or something like it should
go in.

I'd be interested in hearing opinions on this from the people who have been
using LOOP heavily, and also any informed views on when and whether we can
expect a proposal on improved iteration machinery.

-- Scott