Skip to content

p-i-s: defpackage: handle SBCL exts, cerror on unknown option

Phoebe Goldman requested to merge iss147 into master

Per issue 147, this commit makes two (related) changes:

  • When encountering an unknown defpackage option, signal a continuable error of class package-inferred-system-unknown-defpackage-option-error, rather than previously signalling an ecase 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
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?


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.

Edited by Robert Goldman

Merge request reports