p-i-s: defpackage: handle SBCL exts, cerror on unknown option
Per issue 147, this commit makes two (related) changes:
- When encountering an unknown
defpackage
option, signal a continuable error of classpackage-inferred-system-unknown-defpackage-option-error
, rather than previously signalling anecase
fallthrough error. - Infer dependencies from the two nonstandard options
defined by SBCL's package locks extension,
:lock
and:implement
.:lock
introduces no dependencies, while:implement
introduces dependencies as if it was:use
.
This commit also extends the package-inferred-system-test.script
to exercise SBCL's package locks extension.
Assigned to @rgoldman for review, since he assigned the issue to me. CC @Gleefre, who opened the issue.
Other implementations' extensions:
Implementation | Extensions to DEFPACKAGE |
---|---|
CMUCL | None |
Lispworks |
:local-nicknames (already handled), :add-use-defaults 1
|
Allegro |
:implementation-packages (pretty sure this should be ignored because the implementation packages are likely forward references), :alternate-name (ignore), :local-nicknames (already handled), :flat (ignore), hierarchical packages 2
|
clasp | None mentioned in docs |
ECL | :lock |
CCL | None mentioned in docs |
clisp | None mentioned in docs |
MKCL | Don't see any docs at all. Maybe shares the lock API with ECL? |
Notes
See Lispworks docs. As far as I can tell, you just ignore :add-use-defaults
on Lispworks, and probably should raise either a warning or a continuable error on any other implementation.
See Franz's Allegro docs. Franz's hierarchical packages.
Hierarchical packages impose a different package name parsing: there are relative names. I think we can safely ignore this issue for now. If they don't work, it's not this issue that keeps them from working.