From: Christophe R. <cs...@ca...> - 2002-07-16 16:11:17
|
Hi, Now that Dan's nearly reimplemented stack exhaustion checking, I'd like to solicit opinions on what the REPL ought to do with respect to compilation optimization policy. Currently, if you do at the REPL: * (foo 3) what actually happens is (more or less): * (funcall (compile nil (lambda () (declare (optimize (safety 3) (compilation-speed 2) (speed 1) (debug 1) (space 1))) (foo 3)))) [ I apologize in advance for the appalling indentation. ] The problem that I have experience with this is that it interacts badly with PROCLAIM/DECLAIM. A PROCLAIM at the REPL * (proclaim '(optimize (speed 3) (safety 1))) will have no effect on, say, * (defun fast-function (x) ...) because the optimize qualities are hard-coded in src/code/eval.lisp. Of course, I can do * (defun fast-function (x) (declare (optimize (speed 3) (safety 1))) ...) and this will work as expected, but this is not terribly convenient when interacting with lisp from an emacs buffer, say, when doing incremental development ("why is he incrementally developing after optimization, I hear you all cry"). So, what I would like is that the default state of the optimization qualities in src/code/eval.lisp be set to whatever seems sensible (like the above, maybe with slightly higher DEBUG), but that they be removed from the generated lambda so that PROCLAIM and friends can work at the REPL. Does this make sense? Any thoughts? Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2002-07-16 21:20:32
|
On Tue, Jul 16, 2002 at 05:09:45PM +0100, Christophe Rhodes wrote: > Now that Dan's nearly reimplemented stack exhaustion checking, I'd like > to solicit opinions on what the REPL ought to do with respect to > compilation optimization policy. > > Currently, if you do at the REPL: > > * (foo 3) > > what actually happens is (more or less): > > * (funcall (compile nil > (lambda () (declare (optimize (safety 3) > (compilation-speed 2) > (speed 1) > (debug 1) > (space 1))) > (foo 3)))) > > [ I apologize in advance for the appalling indentation. ] > > The problem that I have experience with this is that it interacts badly > with PROCLAIM/DECLAIM. A PROCLAIM at the REPL > > * (proclaim '(optimize (speed 3) (safety 1))) > > will have no effect on, say, > > * (defun fast-function (x) ...) > > because the optimize qualities are hard-coded in src/code/eval.lisp. Of > course, I can do > > * (defun fast-function (x) > (declare (optimize (speed 3) (safety 1))) > ...) > > and this will work as expected, but this is not terribly convenient when > interacting with lisp from an emacs buffer, say, when doing incremental > development ("why is he incrementally developing after optimization, I > hear you all cry"). > > So, what I would like is that the default state of the optimization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > qualities in src/code/eval.lisp be set to whatever seems sensible (like ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the above, maybe with slightly higher DEBUG), but that they be removed > from the generated lambda so that PROCLAIM and friends can work at the > REPL. > > Does this make sense? Any thoughts? I'm not quite sure what you mean here. The way your proposal is phrased, it sounds to me as though eval.lisp would still have its own optimization policy values. But if eval.lisp doesn't put them into the LAMBDA, then what would it do with them? Do you mean that eval.lisp shouldn't have its own versions of optimization policy at all, so that the PROCLAIMed-at-toplevel values would always apply to "interpreted" code (when EVAL punts and asks COMPILE for help)? I think that would be a reasonable replacement for the current behavior, since your example shows the current behavior can be annoyingly surprising and inflexible. Or perhaps you mean that eval.lisp should do some more-complicated defaulting thing, e.g. inserting its preferred policy only when the user hasn't explicitly declared his own policy preference? I'm not sure what to think about this without understanding better how eval.lisp would make its opinions known to the compiler. -- William Harold Newman <wil...@ai...> "That's when the megagod Reality showed up." -- Jessica Mulligan <http://www.skotos.net/articles/BTH_27.shtml> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2002-07-17 07:55:40
|
On Tue, Jul 16, 2002 at 04:14:50PM -0500, William Harold Newman wrote: > On Tue, Jul 16, 2002 at 05:09:45PM +0100, Christophe Rhodes wrote: > > So, what I would like is that the default state of the optimization > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > qualities in src/code/eval.lisp be set to whatever seems sensible (like > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the above, maybe with slightly higher DEBUG), but that they be removed > > from the generated lambda so that PROCLAIM and friends can work at the > > REPL. > > > > Does this make sense? Any thoughts? > > I'm not quite sure what you mean here. Sorry. What I meant was that eval.lisp would no longer have any mention of optimization qualities in it anywhere; my suggested replacement would have a (PROCLAIM '(OPTIMIZE ...)) executed as more or less the last thing before sbcl.core is dumped (after compiling PCL in warm init), where the current (all "1") values (see the end of src/cold/warm.lisp) would be replaced by different defaults for interaction, thus overrideable by the user. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |