james anderson <james.anderson@...> writes:
> good afternoon;
> it appears that sbcl recognizes a prior class definition at compile
> time at top level or in a top level progn only.
> in the code below, the progn-only approaches compile uneventfully
> while the others elicit warnings.
> is there something to learn from this, or does one just structure
> definition macros accordingly?
Last paragraph of CLHS defclass tells:
If a defclass form appears as a top level form, the compiler must make
the class name be recognized as a valid type name in subsequent
declarations (as for deftype) and be recognized as a valid class name
for defmethod parameter specializers and ...
Now looking into the source of where that style-warning is signaled,
that place is responsible for declaring types to Python in the internal
method-lambda. However, the actual relevant part in the code looks like:
(if (typep class '(or built-in-class structure-class))
`(type ,class ,parameter)
;; don't declare CLOS classes as parameters;
;; it's too expensive.
Because in your case, it's all CLOS classes it does not actually make
any difference there.
However, there may be other parts in PCL which just silently give up and
fall back to a very slow path.
> the "muffling" protocol reads as if it offers control specific to
> deletion notes only.
> is it possible to arrange to muffle this particular style warning?
MUFFLE-CONDITIONS is, as far as I read, applicable to anything with a
MUFFLE-WARNING restart which includes conditions signaled by means of
WARN, and also internal compiler conditions.
However, to muffle a particular condition, it needs to have its own name
so you can discriminate it from other conditions. In this particular
case, the code only signals a general style-warning, and muffling all
style-warning sounds like a very bad recipe.
I'm also not convinced that muffling that particular condition would be
a good idea to begin with. An actual PCL expert might want to chime in
here, and explain the pessimistics things that would result from using
non-toplevel DEFCLASS + specializing DEFMETHODS in the same file.
If you really need non-toplevel DEFCLASSes, you should consider moving
them into their own file, loaded before their uses.