In article <4C70E83B.1060906@...>,
Thomas de Grivel <billitch@...> wrote:
> On 08/22/10 01:07, Tobias C Rittweiler wrote:
> > In article<87fwy81j8u.fsf@...>,
> > Christophe Rhodes<csr21@...> wrote:
> >> Tobias C Rittweiler<tcr@...> 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.