Re: Issue "Eliminate forced consing" re-visited

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

> Date: Tue, 23 Aug 88 14:59:23 EDT
> From: "Dan L. Pierson" <pierson%mist@arpa.multimax>
>     
>    > and should, pass unless we are prepared to "depreciate" the sequence
>    > functions entirely.
>   
>    I think that is going a bit far.  Surely the sequence functions are
>    not nearly useless without this change.
>
> Sorry, I don't mean that the sequence functions are useless without
> this change.  "Depreciate" is a technical term [...]  the feature [...]
> may (will?) be removed in a future version.  If we don't want to enhance
> them because we expect them to become obsolete we should also make that
> clear.

I don't see how this explanation invalidates my point.  This change is
not: something we should pass unless we think the sequence functions are
obsolete/perhaps-subject-to-removal anyway (and so not worth bothering to
improve).  That is, we might think the sequence functions are worth having
and still not want this change.

> As I understand it, the problem with supporting OSS by compiler
> optimization with no extensions is that efficient compilation of
> compositions of OSS functions depends on adherence to a specific set
> of constraints.  The OSS package checks for and either corrects or
> signals violations of these constraints.

[I don't insist on *no* extensions.]

> It seems likely that an "ordinary CL compiler" could support some
> OSS-style optimization, but it would probably be restricted to a much
> smaller subset of compositions of sequence operations than OSS.

Why is this?  It can detect the cases where the constraints aren't
met.  Isn't this the same as recognizing the cases where they can be
met?  OK, it can't "correct" any cases that violate the constraints.
How much depends on corrections?

> It would also be harder for a compiler to deal with cases it couldn't
> optimize because, since the programmer hadn't declared any intent, the
> compiler would be unable to distinguish between normal code to which
> an optimization didn't apply and a programmer error that prevented an
> intended optimization.

All that this seems to amount to is that the compiler can't signal an
error: all it can do is not make the optimization.  But that's what
compilers normally do when they can't make an optimization.