From: Nikodemus S. <tsi...@cc...> - 2005-03-01 09:08:37
|
Currently code entered at the REPL is evaluated in a special "interactive" environment with a separate hardcoded policy: (safety 3) (debug 2) (compilation-speed 2) ... rest at 1 Inconsistently, the debugger command loop uses the global policy. Additionally, it is not currently possible to affect global policy in any other way except by PROCLAIM/DECLAIM in the REPL as both COMPILE-FILE and LOAD bind SB-C::*POLICY*. I propose the following: * Remove the separate interactive policy, as it only serves to confuse. * Process initialization files with READ & EVAL, not LOAD, so that global policies, startup package, etc. can be modified by them. * Remove binding for SB-C::*POLICY* from LOAD. However, since this means that third-party code can eg. globally set (SAFETY 0), make top level OPTIMIZE declarations signal style-warnings under LOAD, and add information about changed policy to :VERBOSE output from LOAD. Thereafter current file-local effect could be achived with (eval-when (:compile-toplevel) (proclaim ...)) The two first changes are essentially orthogonal from the third, but not from each other, as AFAIK one of the reasons for the interactive environment magic is the inability to change global policy from initialization files. The second change is IMO required even in the presense of the third, since it makes little sense to bind anything around the initialization file processing. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Brian M. <bma...@cs...> - 2005-03-03 01:04:19
|
On Mar 1, 2005, at 3:05 AM, Nikodemus Siivola wrote: > * Remove the separate interactive policy, as it only serves to > confuse. > > * Process initialization files with READ & EVAL, not LOAD, so that > global policies, startup package, etc. can be modified by them. > > * Remove binding for SB-C::*POLICY* from LOAD. However, since this > means > that third-party code can eg. globally set (SAFETY 0), make top > level > OPTIMIZE declarations signal style-warnings under LOAD, and add > information > about changed policy to :VERBOSE output from LOAD. > > Thereafter current file-local effect could be achived with > > (eval-when (:compile-toplevel) (proclaim ...)) I'll throw my two cents in: I think #1 and #2 are great ideas, but #3 is a terrible idea just as a matter of user expectation. There is quite a lot of source out there that does (declaim (optimize ...)), and we're not gaining anything wrt ANSI by breaking the expectation that this only effects file scope. -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |
From: William H. N. <wil...@ai...> - 2005-03-03 17:03:56
|
On Wed, Mar 02, 2005 at 07:03:49PM -0600, Brian Mastenbrook wrote: > > On Mar 1, 2005, at 3:05 AM, Nikodemus Siivola wrote: > > > * Remove the separate interactive policy, as it only serves to > >confuse. > > > > * Process initialization files with READ & EVAL, not LOAD, so that > > global policies, startup package, etc. can be modified by them. > > > > * Remove binding for SB-C::*POLICY* from LOAD. However, since this > >means > > that third-party code can eg. globally set (SAFETY 0), make top > >level > > OPTIMIZE declarations signal style-warnings under LOAD, and add > >information > > about changed policy to :VERBOSE output from LOAD. > > > > Thereafter current file-local effect could be achived with > > > > (eval-when (:compile-toplevel) (proclaim ...)) > > I'll throw my two cents in: I think #1 and #2 are great ideas, but #3 > is a terrible idea just as a matter of user expectation. There is quite > a lot of source out there that does (declaim (optimize ...)), and we're > not gaining anything wrt ANSI by breaking the expectation that this > only effects file scope. I agree with all your points, but I think I weight the user expectations a little less vs. trying to the right thing. I agree that it's a major drawback that users would tend to be very surprised. However, several times before SBCL has gone and tried to do the tidiest thing which was allowed by the spec (default USE lists on new packages, refusing to redefine unEQL DEFCONSTANTs...). While it has certainly caused plenty of friction, my impression is that there is also a base of support for trying to do the right thing even if it's not what people have come to expect. On the other hand, Nikodemus' LOAD behavior might be less useful than it seems since you can't rely on it portably. Thus, even if you can think of situations where the reliable policy side effects would be useful, you can't use them in portable systems, which would be a drag. So I think in a new version of the ANSI standard this LOAD behavior would be the right thing, but I am less sure that it's the right thing in one implementation. On the third hand, one way that standards converge to the right thing is by implementations showing the way. So I don't know. Maybe I'll be able to develop a more forceful opinion later. -- William Harold Newman <wil...@ai...> When you are the stronger, you ought to tolerate me; for it is your duty to tolerate truth. But when I am the stronger I shall persecute you; for it is my duty to persecute error. -- Thomas Macaulay |
From: Nikodemus S. <tsi...@cc...> - 2005-03-04 10:03:54
|
On Wed, 2 Mar 2005, Brian Mastenbrook wrote: >> * Remove binding for SB-C::*POLICY* from LOAD. However, since this means >> that third-party code can eg. globally set (SAFETY 0), make top level >> OPTIMIZE declarations signal style-warnings under LOAD, and add >> information >> about changed policy to :VERBOSE output from LOAD. >> >> Thereafter current file-local effect could be achived with >> >> (eval-when (:compile-toplevel) (proclaim ...)) > > I'll throw my two cents in: I think #1 and #2 are great ideas, but #3 is a > terrible idea just as a matter of user expectation. There is quite a lot of > source out there that does (declaim (optimize ...)), and we're not gaining > anything wrt ANSI by breaking the expectation that this only effects file > scope. I understand and somwhat agree with the sentiment, but I'm also at a loss to find any justification for file-level policies in CLHS. Especially, consider loading a file that does (DECLAIM (SAFETY 3)); according to my reading of the spec after that we're allowed to expect that our global policy has been set to produce safe-code. (I'm picking (safety 3) here, as that's the only policy with specified effects...) Maybe, to ameliorate the undesirable effects we could extend LOAD with :policy keyword, and have it default from *LOAD-POLICY*, initially T meaning that load-time proclamations can affect global policy. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Brian M. <bma...@cs...> - 2005-03-05 00:28:29
|
On Mar 4, 2005, at 4:03 AM, Nikodemus Siivola wrote: > On Wed, 2 Mar 2005, Brian Mastenbrook wrote: > >>> * Remove binding for SB-C::*POLICY* from LOAD. However, since this >>> means >>> that third-party code can eg. globally set (SAFETY 0), make top >>> level >>> OPTIMIZE declarations signal style-warnings under LOAD, and add >>> information >>> about changed policy to :VERBOSE output from LOAD. >>> Thereafter current file-local effect could be achived with >>> (eval-when (:compile-toplevel) (proclaim ...)) >> >> I'll throw my two cents in: I think #1 and #2 are great ideas, but #3 >> is a terrible idea just as a matter of user expectation. There is >> quite a lot of source out there that does (declaim (optimize ...)), >> and we're not gaining anything wrt ANSI by breaking the expectation >> that this only effects file scope. > > I understand and somwhat agree with the sentiment, but I'm also at a > loss to find any justification for file-level policies in CLHS. Hm. After a reading of the relevant sections, I concede that the load-time effect of declaim should not be file-local. (The compile-time effect is allowed to be, from what I can tell, and this may still be worthwhile.) Your suggestion makes more sense to me now. -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |