[Sbcl-devel] Re: Re: Non-conforming warnings

[Adam W. <li...@co...>]

Hi Christophe Rhodes,

> (I'll see if I can look at screamer later, but no promises... I'm a
> bit busy at the moment)

It's tricky code. In case there's no opportunity to look at it I've
already got it to compile for SBCL by setting
ASDF:*COMPILE-FILE-FAILURE-BEHAVIOUR* to :WARN for the duration of
compilation.

ASDF doesn't appear to provide a way to do this cleanly so I store and set
ASDF:*COMPILE-FILE-FAILURE-BEHAVIOUR* to :WARN in screamer.asd and reset
it to its default in equations.lisp (the file following screams.lisp).

The latest sources are here:
<https://macrology.co.nz/files/cl-screamer-3.24.1-3.tar.bz2>

Here's the output of (require 'screamer) on SBCL:

; loading #P"/usr/share/common-lisp/source/screamer/screamer.asd"
; loading #P"/usr/share/common-lisp/source/cl-plus/cl-plus.asd"
; loading #P"/usr/lib/common-lisp/sbcl/cl-plus/cl-plus.fasl"
; loading #P"/usr/lib/common-lisp/sbcl/screamer/screamer.fasl"
; loading #P"/usr/lib/common-lisp/sbcl/screamer/iterate.fasl"
; loading #P"/usr/lib/common-lisp/sbcl/screamer/primordial.fasl"
; loading #P"/usr/lib/common-lisp/sbcl/screamer/screams.fasl"
style-warning: redefining parse-categories in DEFUN
style-warning: redefining parse-categories-nondeterministic in DEFUN
style-warning: redefining parse in DEFUN
style-warning: redefining parse-nondeterministic in DEFUN
; loading #P"/usr/lib/common-lisp/sbcl/screamer/equations.fasl"
nil

(primordial::prime-ordeal) performs some tests; correctly.

>> Christophe, you didn't comment upon the issue of export warnings. Is it
>> your opinion that these aren't non-conforming and shouldn't be full
>> warnings?
> 
> Isn't the warning only emitted when any DEFPACKAGE form is
> reevaluated, with the package having changed in the meantime?  That
> behaviour is likewise unspecified, I think:
> 
>   If defined-package-name already refers to an existing package, the
>   name-to-package mapping for that name is not changed. If the new
>   definition is at variance with the current state of that package,
>   the consequences are undefined; an implementation might choose to
>   modify the existing package to reflect the new definition. If
>   defined-package-name is a symbol, its name is used.
> 
> (from CLHS DEFPACKAGE)
> 
> The warning is annoying when doing incremental development, sure.  But
> as a matter of pragmatism, it surely isn't a problem for a
> distribution, because I'd have guessed that all the DEFPACKAGEs come
> first, and then modification happens (so you never reevaluate the
> defpackage forms once you've gotten going, as it were).
> 
> I don't know.  I haven't looked at the code in question, so there may
> be some reason for doing things this way.

I guess the answer is to sometimes just avoid DEFPACKAGE, like I did in
cl-plus.

(eval-when (:compile-toplevel :load-toplevel :execute)
  (ignore-errors (make-package '#:cl+ :use '(#:cl))))

(in-package #:cl+)

(export 'defconst)
...

I can compile cl-plus even when I have extra definitions in a pre-existing
CL+ package. And so can others. It's the kind of package prefix that is so
short and useful that it's dogmatic to effectively claim it's reserved by
failing to compile if it's use is out of sync with a pre-existing CL+
package. I could improve the code by generating a style-warning whenever
the CL+ package is already defined.

The package is intended for functionality that supports multiple
implementation compilation, and perhaps functionality so fundamental that
you can't imagine it being left out of any ANSI Common Lisp successor
(e.g. perhaps STRING-INVERT, NSTRING-INVERT and FILE-SIZE).

Regards,
Adam