mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
This fixes the ANSI non-compliance passed down from early
CMUCL (1991-10-31). The bug was that FDEFINITION did not return the
same value as SYMBOL-FUNCTION for symbols (lp#799533). The fix is an
incompatible change but only affects encapsulated (e.g. TRACEd and
SP-PROFILE:PROFILEd) non-generic functions.
However, encapsulations belong to the definition (the name) and not to
the function associated with the name, so (SETF (FDEFINITION NAME) FN)
strips encapsulations from FN and keeps the encapsulations of NAME.
- SB-EXT:UNENCAPSULATED-FUNCTION was added.
- Encapsulated functions are printed as
#<FUNCTION FOO ENCAPSULATED>
or, if they have no proper name, as
#<FUNCTION FOO ENCAPSULATED {B1782332}>
This is the same as for unencapsulated functions except for the
additional " ENCAPSULATED".
- Unused slots were removed from SB-PROFILE:PROFILE-INFO.
- Since generic function identity is stable in face of encapsulation,
CLOS is largely unaffected by this change.
145 lines
4.9 KiB
Plaintext
145 lines
4.9 KiB
Plaintext
SBCL TODO
|
|
=========
|
|
|
|
"There's nothing an agnostic can't do as long as he doesn't know
|
|
whether he believes in anything or not."
|
|
-- Monty Python.
|
|
|
|
"God grant me serenity to accept the code I cannot change, courage
|
|
to change the code I can, and wisdom to know the difference."
|
|
-- Erik Naggum
|
|
|
|
"Accumulation of half-understood design decisions eventually
|
|
chokes a program as a water weed chokes a canal. By refactoring
|
|
you can ensure that your full understanding of how the program
|
|
should be designed is always reflected in the program. As a water
|
|
weed quickly spreads its tendrils, partially understood design
|
|
decisions quickly spread their effects throughout your program. No
|
|
one or two or even ten individual actions will be enough to
|
|
eradicate the problem."
|
|
-- Martin Fowler, in _Refactoring: Improving the Design of Existing
|
|
Code_, p. 360
|
|
|
|
"I wish I didn't know now what I didn't know then."
|
|
-- Bob Seger
|
|
|
|
This files is maintained as part of the SBCL distribution, and
|
|
describes flying pies and moons on sticks that SBCL developers dream
|
|
about. The items are in no particular order.
|
|
|
|
The omission of an item is no guarantee that no-one would like it,
|
|
just like the inclusion of an item is no guarantee that someone is
|
|
actively working on it.
|
|
|
|
In addition to this file, there is the BUGS file, and there are also
|
|
hundreds of FIXME notes in the sources. (Things marked as KLUDGE are
|
|
in general things which are ugly or confusing, but that, for
|
|
whatever reason, may stay that way indefinitely.)
|
|
|
|
THREADING INTERFACE
|
|
|
|
SB-THREAD has some problems: recursivity of a mutex should probably
|
|
be a feature of the mutex, and not of the lexical location. Thread
|
|
local variables are needed. Sessions and sharing the terminal need
|
|
to be thought about.
|
|
|
|
PEEPHOLE OPTIMIZER
|
|
|
|
Have you ever read SBCL disassembly?
|
|
|
|
FINISHING EXTERNAL FORMATS
|
|
|
|
Byte order marks. Newline conventions. A way to specify an external
|
|
format without needing to duplicate code. Fixing the inefficiencies.
|
|
|
|
TIMEOUTS
|
|
|
|
Asyncronous unwinds suck horribly, but to implement reliable systems
|
|
one simply needs timeouts. These should probably be local, since
|
|
otherwise they effectively become asynchronous unwinds. Basically,
|
|
for any potentially blocking operation there should be a :TIMEOUT
|
|
arguent (or a version of the operation that accepts the argument).
|
|
|
|
ADVICE/FWRAP
|
|
|
|
SBCL has an internal function encapsulation mechanism, and is able to
|
|
install breakpoint to function start/end -- this is used to implement
|
|
the instrumentation based profiler and tracing. It would be good to
|
|
have this as an exported interface.
|
|
|
|
POLICY MADNESS
|
|
|
|
The interactions between various optimization policies are far from
|
|
obvious. Someone should figure out how to make this better, and fix
|
|
it. One option would be to have just a few (eg. DEBUG, SMALL,
|
|
FAST-SAFE, FAST-UNSAFE) "dominant" policies, and expose the rest
|
|
as separately declarable optimization toggles.
|
|
|
|
INHIBIT-WARNINGS really needs to go away.
|
|
|
|
WINDOWS
|
|
|
|
Needs love.
|
|
|
|
DARWIN
|
|
|
|
Needs love, particularly threads and exceptions/signals.
|
|
|
|
DRAGONFLY
|
|
Multithreading does not work. Possibly because of bug in mmap/munmap.
|
|
|
|
MISC CLEANUPS
|
|
|
|
These need to be taken a good look at -- it might be that some of them
|
|
are already done, or otherwise no longer relevant.)
|
|
|
|
* EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanups:
|
|
** make %COMPILE understand magicality of DEFUN FOO
|
|
w.r.t. e.g. preexisting inlineness of FOO
|
|
** use %COMPILE where COMPILE-TOP-LEVEL used to be used
|
|
** remove redundant COMPILE-TOP-LEVEL and
|
|
FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
|
|
* miscellaneous simple refactoring
|
|
* belated renaming:
|
|
** rename %PRIMITIVE to %VOP
|
|
** A few hundred things named FN should be named FUN
|
|
* These days ANSI C has inline functions, so..
|
|
** redo many cpp macros as inline functions:
|
|
HeaderValue, Pointerp, CEILING, ALIGNED_SIZE,
|
|
GET_FREE_POINTER, SET_FREE_POINTER,
|
|
GET_GC_TRIGGER, SET_GC_TRIGGER, GetBSP, SetBSP,
|
|
os_trunc_foo(), os_round_up_foo()
|
|
** remove various avoid-evaluating-C-macro-arg-twice
|
|
cruft
|
|
* Some work on conditions emitted by the system
|
|
** eliminate COMPILER-WARN and COMPILER-STYLE-WARN, which
|
|
were simply limited versions of WARN and STYLE-WARN.
|
|
** eliminate use of INHIBIT-WARNINGS by code emitted by the
|
|
system from user code.
|
|
** cause use of INHIBIT-WARNINGS to signal a STYLE-WARNING.
|
|
** eliminate use of INHIBIT-WARNINGS within the system
|
|
** deprecate INHIBIT-WARNINGS, causing its use to signal a
|
|
full WARNING.
|
|
** begin work on developing a class hierarchy of conditions
|
|
along semantic lines.
|
|
|
|
PCL INTEGRATION
|
|
|
|
AKA CLOS in cold init.
|
|
|
|
HIGH LEVEL SOCKET INTERFACE
|
|
|
|
Something slightly above the level of BSD sockets would be nice.
|
|
|
|
RPC INTERFACE
|
|
|
|
For talking with other processes.
|
|
|
|
(MOSTLY) PARALLEL GC
|
|
|
|
Several algorithms exist, even one would be nice.
|
|
|
|
INCREMENTAL GC
|
|
|
|
For those who need it.
|