mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
0aecc2b201
Declassification of INSTANCE and FUNCALLABLE-INSTANCE.
It turns out that the classes INSTANCE and
FUNCALLABLE-INSTANCE, as expressed in instance-pointer-lowtag
and funcallable-instance-widetag, are incompatible with the
MOP's notion of classes: the types INSTANCE and
FUNCALLABLE-INSTANCE are necessarily disjoint (no instance can
have a widetag of anything other than instance-header-widetag),
but FUNCALLABLE-STANDARD-OBJECT is required to be a subclass of
STANDARD-OBJECT, and must therefore have the superclasses of
STANDARD-OBJECT among its superclasses. If INSTANCE is one of
those, FUNCALLABLE-INSTANCE cannot be, so F-S-Os would not be of
type FUNCALLABLE-INSTANCE (which is wrong); if it is not one of
those, then ordinary S-Os would not be of type INSTANCE (which
is wrong). CMUCL, at the time of writing, exhibits type system
confusion in this area, as demonstrated by CSR cmucl-imp
2005-09-0x).
So, we need to do something else; probably most straightforward
to make INSTANCE and FUNCALLABLE-INSTANCE named types, as they
are of the same order of specialness as e.g. T -- not quite as
special, but almost. Some hacking later...
... the usual type system dance. Play whack-a-mole with test
failures and compilation failures until they all go
away. Primtype, class, typetran, and so on are
fiddled with.
... somewhat hacky code for determining when a class is subtypep
instance / funcallable-instance.
... different hard-coded constants for genesis; don't make a
special instance-layout, because the instance class is
gone.
... just to prove we've achieved something, make STANDARD-OBJECT
a superclass of FUNCALLABLE-STANDARD-OBJECT.
(Supporting METAOBJECT should be straightforward now)
... many many new tests, both of the before-xc variety (it's
amazing in how many ways I can get the type system
wrong) and of the regular form. Also add some
ctor tests that aren't exercised yet.
|
||
|---|---|---|
| .. | ||
| asdf | ||
| asdf-install | ||
| sb-aclrepl | ||
| sb-bsd-sockets | ||
| sb-cltl2 | ||
| sb-executable | ||
| sb-grovel | ||
| sb-introspect | ||
| sb-md5 | ||
| sb-posix | ||
| sb-rotate-byte | ||
| sb-rt | ||
| sb-simple-streams | ||
| sb-sprof | ||
| .cvsignore | ||
| asdf-module.mk | ||
| asdf-stub.lisp | ||
| code-extras.lisp | ||
| compiler-extras.lisp | ||
| experimental-thread.patch | ||
| README | ||
| stale-symbols.lisp | ||
| STANDARDS | ||
| vanilla-module.mk | ||
This directory is for extensions to SBCL. They aren't necessary for
core SBCL functionality, or else they'd be built into the main SBCL
binary automatically. And they're not portable Common Lisp, or they'd
be put elsewhere (see http://sbcl.sf.net/libs.php for pointers)
There are two kinds of contrib module in this directory:
* Newer contrib modules conform to the contrib standard (see
STANDARDS) and are automatically built and installed along with
SBCL itself. Each of these is in its own subdirectory with a
Makefile, and can be loaded with REQUIRE.
* Older standalone files in the contrib directory itself are
effectively unpackaged and may or may not work with the current
SBCL version.
Some good candidates for future extensions here are:
* bindings to existing foreign libraries (e.g. to a regexp library
like PCRE, or to a compression library like zlib, or to a graphics
library like Tk)
* new libraries (e.g. a CORBA interface)
* low-level hooks into SBCL needed to interface it to some wrapper
system (e.g. to interface to a graphical debugger of some sort)
* a too-alpha-to-be-supported-yet tree shaker
SBCL extensions of less general interest, e.g. a binding to the C
interface of the Oracle RDBMS, or particularly large extensions, e.g.
big graphics frameworks, can also be associated with the SBCL project,
but instead of being included in this directory as part of the
distribution, they will be made available or linked to on the SBCL
project web site.