> Ingvar <ingvar@...> writes:
> > And now with "diff -u" patch-file.
> > +(defmacro compiler-note-conditional (note-type format-string &rest format-args)
> > + `(progn (unless (or ,@(loop for sym in note-type collect (list 'member sym '*ignore-compiler-note-class-list*)))
> > + (compiler-note ,format-string ,@format-args))
> > + (values)))
> > +
> > - (compiler-note
> > + (compiler-note-conditional '(:return)
This one will.
> > - (give-up-ir1-transform "BOOLE code is not a constant."))
> > + (give-up-ir1-transform '(:boole :no-inline) "BOOLE code is not a constant."))
This one won't.
> Here's a good argument for more type-checking: those QUOTEs, if I'm not
> mistaken, are going to cause a problem. :-)
The ones in calls to COMPILER-NOTE-CONDITIONAL (it's a macro, so...).
> OK, I think this is a good start. However, I think I would rather see
> something that uses the condition system. The comment above
> COMPILER-NOTE says that it used to signal conditions; however, in the
> process of modernising the code, that was removed, basically because
> in SBCL a compiler note really is a note, not a STYLE-WARNING. I
> think it ought to be possible to reintroduce conditions for compiler
> notes, with a hierarchy that looks something like
> SIMPLE-COMPILER-NOTE (mixin: SIMPLE-CONDITION, for uncategorized)
That would probably make sense. Having a slot for "what type of note is this"
and then selectively ignore issuing notes on that (or possibly re-signal and
do nothing if not caught). the main reason I went with (initially)
instrumenting COMPILER-NOTE calls was to modify the code as little as
possible. Alas, it would probably have benefited from the experimentation I
did after having found so few calls to COMPILEr-NOTE being done before
introducing COMPILER-NOTE-CONDITIONAL. It did give me an idea of rioughly how
I wanted things, so I guess it's OK in the long run.
> Then you can get the effect of your patch by having an outer handler,
> discarding the condition based on its type (and a special variable,
> say *ignored-note-types*); but also user code can handle these beasts
> selectively, maybe with a declaration interface to quieten the
> Does that make any sense? I suppose the thing that using the
> condition system buys us is a little more power for reflection.
Yup. Introspection and reflection is good. The big workload is probably going
to be adding suitable typing to the existing messages anyhow.