12:08:43jackdanielShinmera: very cool indeed. do you use lem?
12:09:00ShinmeraI'm not very adventurous in my tool use, so no
12:09:47ShinmeraBut if the project keeps trucking along as well as it has so far I very well might in the future :)
12:11:11pveSpeaking of conditions, SBCL signals a warning when a defpackage form is evaluated and the package exports symbols that are not specified by the defpackage form ("WARNING: ... also exports the following symbols: ...").
12:11:40pveMy tests show that CCL does not signal such a warning. Is this unique to SBCL, or do other implementations also do this?
12:12:09jackdanielit is a warning that sbcl devs found to be an important clue to the programmer, it is not demanded by the standard
13:51:20scymtymthe reason for SBCL's default behavior is that the specification says "If the new definition is at variance with the current state of that package, the consequences are undefined". the behavior can be customized: https://www.sbcl.org/manual/#Package-Variance
13:54:11scymtymcounterintuitively, requesting the :ERROR behavior makes it easier for a compilation to succeed since restarts for (interactively) resolving the variance issues are established when an error is signaled but not when a warning is signaled