Tomohiro Matsuyama <tomo@...> writes:
> Hi all,
> I've recently came up with a new idea: user extensible packages. The
> mechanism is similar to user extensible sequences (SB-SEQUENCE). ANSI
> packages would be instances of STANDARD-PACKAGE class which is a
> subclass of PACKAGE class.
> MAKE-PACKAGE, FIND-PACKAGE, INTERN, and others functions around
> packages will be still functions, but they rather delegate to their
> generic functions like MAKE-PACKAGE-UNDER, FIND-PACKAGE-UNDER,
> INTERN-UNDER. Such generic functions will take another argument of the
> context package.
> With user extensible packages, we can implement hierarchical packages
> and locally-renamed packages without changing the compiler. Cool!
> Isn't it?
Yes. (I would like this, and also a similar RANDOM protocol).
> So, I tried to make SB!XC:PACKAGE located in src/code/package.lisp a
> class metaobject, but failed to compile SBCL in target-2 stage (SEGV).
This is basically not going to work straightforwardly, because the
cross-compiler has not compiled CLOS (and so it is not available when
target-2 starts) -- most of target-2 is in fact compiling CLOS. So
everything that happens before has to be expressed in terms of non-CLOS
> I don't understand SBCL internals very well. Could someone implement
> my idea or give me an advice?
The good news is "sort of": a while ago I had a tree which implemented a
hack, allowing the user (and the cross-compiler) to define a struct
which could later be subclassable by standard objects. This would give
a more natural feeling, but it isn't strictly necessary: as long as the
functional protocol in the various package functions is in place (with a
default implementation for the vanilla standard-package class), it is
possible to implement everything using structs without worrying too much
about the bootstrapping issues.
More concretely, try
;; slots from current sb!xc:package go here
(defun intern (name package)
(standard-package (%standard-intern name package))
(sb!xc:package (sb!package:intern name package))))
then to experiment with different protocols the user can simply define
substructs of cl:package (after bootstrapping) and methods on
e.g. sb!package:intern for their new structure class.