Re: [Sbcl-devel] DEFPACKAGE's "also exports" queerness

[Tobias C R. <tc...@fr...>]

In article <4C7...@gm...>,
 Thomas de Grivel <bil...@gm...> wrote:

> On 08/22/10 01:07, Tobias C Rittweiler wrote:
> > In article<87f...@ca...>,
> >   Christophe Rhodes<cs...@ca...>  wrote:
> >
> >> Tobias C Rittweiler<tc...@fr...>  writes:
> >>
> >>> I've raised the point pretty much on each time I've been bitten
> >>> by it because it's plain annoying. So far only on chat as far
> >>> as I remember. Funnily, I can never remember what answers I
> >>> got. I don't think an definitive answer ever came up anyway.
> >>>
> >>> Could we, please, make the
> >>>
> >>>    "FOO also exports the following symbols:"
> >>>
> >>> not be a full warning but merely a style-warning?
> >>
> >> CLHS on DEFPACKAGE
> >>
> >> | If the new definition is at variance with the current state of that
> >> | package, the consequences are undefined
> >>
> >> It is usual for SBCL to warn (or error) in places with undefined
> >> consequences.
> >
> > And it's usual a good thing. I'm not questioning the usefulness
> > of that policy, I'm questioning the usefulness of its application
> > in this particular case.
> >
> > What's the use of the warning except for exercising this
> > very passage? Aren't the consequences in fact harmless
> > for my particular case in SBCL? Further, aren't they
> > harmless in all implementations being used? Perhaps I'm
> > missing something here.
> >
> > In case it is harmless, again, what's the use of the warning
> > for me? Comparing for example to modifying literal data,
> > that's not just non-conformant but can actually result in
> > surprising behavior.
> 
> The harmless case is inconclusive, what matters is that it could be harmful.

Please explain to me how it could be harmful.

  
> >> If some of sbcl's contribs aren't reloadable because of this undefined
> >> behaviour, the real fix is to rework the contribs so that they don't
> >> invoke undefined behaviour.
> >
> > ASDF's :FORCE T and SB-POSIX was just an example. Another is
> > that if I remove a symbol from a defpackage's :export list,
> > reloading that file or the system containing it will fail
> > until I manually unexport the respective symbol.
> 
> I agree, it is very annoying.
> 
> I think a sensible solution is define two restarts for easy unexporting 
> and uninterning of the problematic symbol. Would it pose any problem to 
> do so ?

How would you invoke the restarts? It's just a warning after all.
 
  -T.