- 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, _Refactoring: Improving the Design
- of Existing Code_, p. 360
-===============================================================================
-some things that I'd like to do in 0.6.x, in no particular order:
--------------------------------------------------------------------------------
-PROBLEM:
- As long as I'm working on the batch-related command-line options,
- it would be reasonable to add one more option to "do what I'd want",
- testing standard input for non-TTY-ness and running in no-programmer
- mode if so.
-FIX:
- ?? Do it.
--------------------------------------------------------------------------------
-PROBLEM:
- I used CMU CL for years, and dozens of times I cursed the
- inadequate breakpoint-based TRACE facility which doesn't work on
- some functions, and I never realized that there's a wrapper-based
- facility too until I was wading through the source code for SBCL.
- Yes, I know I should have RTFM, but there is a lot of M..
- (By the way, it would also be nice to have tracing behave
- better with generic functions. TRACEing a generic function probably
- shouldn't prevent DEFMETHOD from being used to redefine its
- methods, and should perhaps trace each of its methods as well
- as the generic function itself.)
-FIX:
- ?? possibility 1: Add error-handling code in ntrace.lisp to
- catch failure to set breakpoints and retry using
- wrapper-based tracing.
- ?? possibility 2: Add error-handling code in ntrace.lisp to
- catch failure to catch failure to set breakpoints and output
- a message suggesting retrying with wrapper-based breakpoints
- ?? possibility 3: Fix the breakpoint-based TRACE facility so that
- it always works.
--------------------------------------------------------------------------------
-PROBLEM:
- My system of parallel build directories seems to add
- complexity without adding value.
-FIX:
- ?? Replace it with a system where fasl output files live in the
- same directories as the sources and have names a la
- "foo.fasl-from-host and "foo.fasl-from-xc".
- ?? (Perhaps something else will be required in order to port
- to Microsoft Windows, since its filesystem doesn't have
- symbolic links.)
--------------------------------------------------------------------------------
-PROBLEM:
- It might be good to use the syntax (DEBUGGER-SPECIAL *PRINT-LEVEL*)
- etc. to control the in-the-debug-context special variables. Then we
- wouldn't have to pick and choose which variables we shadow in the
- debugger.
- The shadowing values could also be made persistent between
- debugger invocations, so that entering the debugger, doing
- (SETF *PRINT-LEVEL* 2), and exiting the debugger would leave
- (DEBUGGER-SPECIAL *PRINT-LEVEL*) set to 2, and upon reentry to the
- debugger, *PRINT-LEVEL* would be set back to 2.
-FIX:
- ??
--------------------------------------------------------------------------------
-PROBLEM:
- I still haven't cleaned up the cut-and-paste programming in
- * DEF-BOOLEAN-ATTRIBUTE, DELETEF-IN, and PUSH-IN
- * SB!SYS:DEF!MACRO ASSEMBLE and SB!XC:DEFMACRO ASSEMBLE
-FIX:
- ??
--------------------------------------------------------------------------------
-PROBLEM:
- We be able to get rid of the IR1 interpreter, which would
- not only get rid of all the code in *eval*.lisp, but also allow us to
- reduce the number of special cases elsewhere in the system. (Try
- grepping for 'interpret' sometime.:-) Making this usable might
- require cleaning up %DEFSTRUCT, %DEFUN, etc. to use EVAL-WHEN
- instead of IR1 transform magic, which would be a good
- thing in itself, but might be a fair amount of work.)
-FIX:
- ?? Delete, delete, delete.
-===============================================================================
-other known issues with no particular target date:
-
-bugs listed on the man page
-
-more regression tests
-
-byte compilation of appropriate parts of the system, so that the
-system core isn't so big
-
-Search for unused external symbols (ones which are not bound, fbound,
-types, or whatever, and also have no other uses as e.g. flags) and
-delete them. This should make the system core a little smaller, but
-is mostly useful just to make the source code smaller and simpler.
-
-adding new FOPs to provide something like CMU CL's FOP-SYMBOL-SAVE and
-FOP-SMALL-SYMBOL-SAVE functionality, so that fasl files will be more
-compact. (FOP-SYMBOL-SAVE used *PACKAGE*, which was concise but allowed
-obscure bugs. Something like FOP-LAST-PACKAGE-SYMBOL-SAVE could have
-much of the same conciseness advantage without the bugs.)
-
-hundreds of FIXME notes in the sources from WHN
-
-various other unfinished business from CMU CL and before, marked with
- "XX" or "XXX" or "###" or "***" or "???" or "pfw" or "@@@@" or "zzzzz"
-or probably also other codes that I haven't noticed or have forgotten.
-
-(Things marked as KLUDGE are in general things which are ugly or
-confusing, but that, for whatever reason, may stay that way
-indefinitely.)
+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?
+
+DEFGLOBAL
+
+ Global lexical variables. Esp. since with threads special variable
+ accesses is no speed daemon.
+
+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, and it would be good if the
+ SYMBOL-FUNCTION / FDEFINITION confusion was fixed: currently the
+ latter returns the underlying definition, whereas the first returns
+ the encapsulation.
+
+GENERIC FUNCTION TRACING
+
+ This sucks currently. It would also be good to be able to trace
+ individual methods.
+
+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.
+
+ MAYBE-INLINE is also nice, but it would be good if someone could
+ figure out how to get rid of it while retaining the semantics it
+ provides. Inlining recursive functions is also something to think
+ about.
+
+ INHIBIT-WARNINGS really needs to go away.
+
+WINDOWS
+
+ Needs love.
+
+DARWIN
+
+ Needs love, particularly threads and exceptions/signals. slam.sh is
+ also broken there.
+
+FUNCTION NAMES
+
+ We'd like to be able to (SETF %FUNCTION-NAME) on a closure.
+
+UNDEFINED FUNCTION / VARIABLE RESTARTS
+
+ You know, like Allegro is reputed to have.
+
+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
+ * outstanding embarrassments
+ ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's
+ reasonable to support this as a crutch when initially
+ bootstrapping from balky xc hosts with their own
+ idiosyncratic ideas of what merits FAILURE-P, but it's
+ embarrassing to have to use it when bootstrapping
+ under SBCL!),
+ * 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.
+
+CROSS PLATFORM GUI
+
+ Since this is a high priority we're waiting for PHP coders to
+ offer their help to build a website about this.
+
+BLOCK COMPILATION
+
+ You know, like CMUCL does.
+
+(MOSTLY) PARALLEL GC
+
+ Several algorithms exist, even one would be nice.
+
+INCREMENTAL GC
+
+ For those who need it.
projects / sbcl.git / blobdiff