Alexey Dejneka wrote:
> You mean (SORT (THE LIST ...) ...)?
Indeed, sorry for the error.
> > Also, I wonder if
> > those warnings should vary based on optimization settings.
> This is interesting. How do you want them to depend?
I think how it is set now, where a warning is giving about a potential
serious problem with optimization is reasonable: it tells the user
they may have a problem from the application of optimization to the
code. From a different perspective, though, the offending code (sort
(loop ...)) is subject to type errors no matter what the optimization
setting. Thus, if the compiler thinks the user has a potential
run-time type problem, then one could argue that such a potential
problem should always be warned or not warned.
> I think it would be much better to rework SBCL to signal a WARNING
> only for a manifest error. What do you (and others) think about
> issue a full WARNING when a type assertion contradicts a full type
> the argument, and a STYLE-WARNING when it contradicts a type on one
> of the paths?
I suppose it could depend on how serious a problem a run-time type
error could cause. If trying (sort (loop ...)) is going to crash the
lisp kernel if sort does not get a list, I think a warning could be
consider reasonable. On the other hand, if the user is just going to
get to the debugger if there is a run-time error, I don't see the need
for a warning.
I wonder, will putting a type specifier really change the run-time
behavior? In the previous example, one can put (sort (the list ...)),
to get rid of the compiler warning. But, will that change the run-time
behavior if the object in question is not a list?