Re: [Sbcl-devel] Policy control

[William H. N. <wil...@ai...>]

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