William Harold Newman <william.newman@...> writes:
> On Tue, Jan 14, 2003 at 03:23:49PM +0000, Christophe Rhodes wrote:
> > I was thinking that something along these lines would probably be a
> > maintainability win -- certainly, it's better to ask for whichever
> > optimization quality you want if there is a particular need. What's
> > causing the test you've commented out to fail, though?
> > My particular motivation for it this time, apart from this, is that it
> > might be a way that we could allow users to quieten warnings and style
> > warnings under certain circumstances. I'm even less sure what the
> > interface would look like, but maybe something like
> > (locally
> > (declare (suppress function-redefinition-warning))
> > (defun foo (x) ...))
> I think for our work internally implementing the guts of SBCL itself
> it's probably good to have these optimization qualities explicitly
> (e.g. here to make XEPs be implemented the way we intend) instead of
> doing clever wordplay on the standard optimization qualities. But as
> longtime readers are aware, I'm usually skeptical of exposing more
> features and options to the general userbase.
> I do agree that the suppression of warnings (and optimization notes)
> is something that's hard to get right for everyone in a single
> default, and I agree we might benefit from some customization. But for
> the specific annoyance of function redefinition, if anyone's
> sufficiently irritated by the current suboptimal behavior, the obvious
> first thing to do is remember where (what place in what file) the last
> definition came from, and suppress the warning when the new definition
> comes from the same place. That'd fix the nuisance of
> (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL) (DEFUN ...)) when you
> compile and load in the same SBCL image, which I think is almost
> everyone's top annoyance about the current system.
There is a slight technical catch, I think, in that compiling and
loading a file with
(eval-when (:compile-toplevel :load-toplevel :execute)
(defun foo (x) x))
first (on compiling) gets you a FOO compiled from
#((LAMBDA () (SB-INT:NAMED-LAMBDA FOO (X) (BLOCK FOO X))))
and (on load) the new FOO is compiled from
but I suppose this problem is one that needs to be solved, that's
all. And I think a fix along these lines is probably better than a
However, as a better example of what I was trying to do, consider (a
(defun foo (x)
(declare (optimize (speed 3) (safety 1)))
(declare (type (simple-array * (*)) x))
(aref x 2))
If FOO is truly a function that has to deal quickly with any kind of
vector, and is so by design, wouldn't it be nice to be able to turn
off the efficiency note that results because we have to do generic
; note: unable to
; avoid runtime dispatch on array element type
; Upgraded element type of array is not known at compile time.
This is what SB-EXT:INHIBIT-WARNINGS currently does, but that's a bit
of a scary sledgehammer to use...
> > If we do go down this route, are there any other qualities that you've
> > noticed that can be abstracted out? I suppose there are the ones in
> > src/compiler/main.lisp; for instance:
> > (when (policy *lexenv* (>= speed compilation-speed))
> > (maybe-mumble "copy ")
> > (copy-propagate component))
> > which could be turned into (optimize (propagate-copies 3)), I
> > guess...
> That seems like a case of exposing more complex behavior to the end
> user. Are you sure it's worthwhile to do that for this? (with all the
> entailed documenting the feature, keeping the feature stable for
> years, and convincing your users to customize their code to your
I hear the worry, but what I'd like to do is expose complex behaviour
to the end user without the requirement for documenting, stability and
I dunno. It may be that there are in fact no or very few usage cases
where this specific exposure to the user would be useful. But, in
general, experimentation needs to happen for anyone to find out, and
(putting myself on a limb here) I don't think that I'd feel bad for
experimenting with a feature without declaring it stable and an
interface for years to come.
Maybe a better example of the attitude I'm trying to take can be seen
if we consider Dan's example for how to do inline assembly, at
wouldn't feel at all bad about changing the interface to DEFKNOWN and
DEFINE-VOP if it turned out to be necessary, despite the fact that
these interfaces may be useful to a certain class of user.
In other words, I think it would cost very little to alter
(when (policy *lexenv* (> speed compilation-speed))
(when (policy *lexenv* propagate-copies)
in the SBCL source code itself, and not document it at all. This
would still expose the functionality to the user without, as far as I
can see, imposing a maintenance requirement.
Does that make sense?
One thing that should also be considered, incidentally, is that while
it is possible to allow for implementation-dependent declarations in
user code, with
(DECLAIM (DECLARATION FOO))
it isn't possible to do the same with OPTIMIZE qualities. This could
be seen as an argument for making the interface to these new qualities
one or the other, depending on your point of view... :-)
> > * On X86 I is represented as a tagged integer.
> > I don't think there's really any way that one can represent I as a
> > bare (machine) integer -- I think that in the threaded SBCL case,
> > another thread could request a GC (or there could be an asynchronous
> > interrupt, or whatever), and having a bare integer could be
> > disastrous.
> Why disastrous? Maybe I'm being obtuse or just insufficiently
> caffeinated at the moment, or maybe things are clearer when you have
> some experience with the precise-GC architectures, but the problem
> here isn't obvious to me.
Sorry... I was clearly undercaffeinated when I wrote this. Of course
one ends up with untagged integers, and I was just not thinking
clearly. :-/ I still want to run with my idea of unrolling the loop
four times, though :-)
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)