Re: issue COMPILE-ARGUMENT-PROBLEMS

[KMP@STONY-BROOK.SCRC.Symbolics.COM]

[This message has been redirected:
  Sorry. I sent that message to the wrong list.
    CL-Cleanup@SAIL.Stanford.EDU has been removed;
    CL-Compiler@SAIL.Stanford.EDU has been added.]

I had forgotten the issue was voted on.

I do, however, think there are substantial benefits to be gained from my
new proposal over the other one. I think any definition of COMPILE which
permits it to err at random (which is pretty much how I feel about all
these "is an error" situations) severely cripples the usefulness of COMPILE
in really portable code. Signalling an error rather than quietly returning
seems useless. The only  reason I can think of to signal an error in general
is if there was some danger to be avoided or more than one way you could
go and you want to allow user intervention. In this case, I think people
always do just one thing: say to themselves "oh, i guess I won't compile
this". We might as well let the system do it for them.

So my inclination is to say yes, that we should reopen the issue.
My understanding was that the primary justification of the previous proposal
over this one is that it was what you thought was the "best that could be
hoped for". My inclination is to believe that this raises the least common
denominator without crossing that line where we get bogged down in
capabilities of particular implementations, etc.

Does you (or does anyone) have reason to believe that the new proposal
I've just circulated would cause any kind of problem?