TODO

   1 SBCL TODO
   2 =========
   3
   4      "There's nothing an agnostic can't do as long as he doesn't know
   5      whether he believes in anything or not."
   6        -- Monty Python.
   7
   8      "God grant me serenity to accept the code I cannot change, courage
   9      to change the code I can, and wisdom to know the difference."
  10        -- Erik Naggum
  11
  12      "Accumulation of half-understood design decisions eventually
  13      chokes a program as a water weed chokes a canal. By refactoring
  14      you can ensure that your full understanding of how the program
  15      should be designed is always reflected in the program. As a water
  16      weed quickly spreads its tendrils, partially understood design
  17      decisions quickly spread their effects throughout your program. No
  18      one or two or even ten individual actions will be enough to
  19      eradicate the problem."
  20        -- Martin Fowler, in _Refactoring: Improving the Design of Existing
  21           Code_, p. 360
  22
  23      "I wish I didn't know now what I didn't know then."
  24        -- Bob Seger
  25
  26   This files is maintained as part of the SBCL distribution, and
  27   describes flying pies and moons on sticks that SBCL developers dream
  28   about. The items are in no particular order.
  29
  30   The omission of an item is no guarantee that no-one would like it,
  31   just like the inclusion of an item is no guarantee that someone is
  32   actively working on it.
  33
  34   In addition to this file, there is the BUGS file, and there are also
  35   hundreds of FIXME notes in the sources. (Things marked as KLUDGE are
  36   in general things which are ugly or confusing, but that, for
  37   whatever reason, may stay that way indefinitely.)
  38
  39 THREADING INTERFACE
  40
  41   SB-THREAD has some problems: recursivity of a mutex should probably
  42   be a feature of the mutex, and not of the lexical location. Thread
  43   local variables are needed. Sessions and sharing the terminal need
  44   to be thought about.
  45
  46 PEEPHOLE OPTIMIZER
  47
  48   Have you ever read SBCL disassembly?
  49
  50 DEFGLOBAL
  51
  52   Global lexical variables. Esp. since with threads special variable
  53   accesses is no speed daemon.
  54
  55 FINISHING EXTERNAL FORMATS
  56
  57   Byte order marks. Newline conventions. A way to specify an external
  58   format without needing to duplicate code. Fixing the inefficiencies.
  59
  60 TIMEOUTS
  61
  62   Asyncronous unwinds suck horribly, but to implement reliable systems
  63   one simply needs timeouts. These should probably be local, since
  64   otherwise they effectively become asynchronous unwinds. Basically,
  65   for any potentially blocking operation there should be a :TIMEOUT
  66   arguent (or a version of the operation that accepts the argument).
  67
  68 ADVICE/FWRAP
  69
  70   SBCL has an internal function encapsulation mechanism, and is able to
  71   install breakpoint to function start/end -- this is used to implement
  72   the instrumentation based profiler and tracing. It would be good to
  73   have this as an exported interface, and it would be good if the
  74   SYMBOL-FUNCTION / FDEFINITION confusion was fixed: currently the
  75   latter returns the underlying definition, whereas the first returns
  76   the encapsulation.
  77
  78 GENERIC FUNCTION TRACING
  79
  80   This sucks currently. It would also be good to be able to trace
  81   individual methods.
  82
  83 POLICY MADNESS
  84
  85   The interactions between various optimization policies are far from
  86   obvious. Someone should figure out how to make this better, and fix
  87   it. One option would be to have just a few (eg. DEBUG, SMALL,
  88   FAST-SAFE, FAST-UNSAFE) "dominant" policies, and expose the rest
  89   as separately declarable optimization toggles.
  90
  91   MAYBE-INLINE is also nice, but it would be good if someone could
  92   figure out how to get rid of it while retaining the semantics it
  93   provides. Inlining recursive functions is also something to think
  94   about.
  95
  96   INHIBIT-WARNINGS really needs to go away.
  97
  98 WINDOWS
  99
 100   Needs love.
 101
 102 DARWIN
 103
 104   Needs love, particularly threads and exceptions/signals. slam.sh is
 105   also broken there.
 106
 107 FUNCTION NAMES
 108
 109   We'd like to be able to (SETF %FUNCTION-NAME) on a closure.
 110
 111 UNDEFINED FUNCTION / VARIABLE RESTARTS
 112
 113   You know, like Allegro is reputed to have.
 114
 115 MISC CLEANUPS
 116
 117   These need to be taken a good look at -- it might be that some of them
 118   are already done, or otherwise no longer relevant.)
 119
 120    * EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanups:
 121         ** make %COMPILE understand magicality of DEFUN FOO
 122                 w.r.t. e.g. preexisting inlineness of FOO
 123         ** use %COMPILE where COMPILE-TOP-LEVEL used to be used
 124         ** remove redundant COMPILE-TOP-LEVEL and
 125                 FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
 126    * outstanding embarrassments
 127         ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's
 128                 reasonable to support this as a crutch when initially
 129                 bootstrapping from balky xc hosts with their own
 130                 idiosyncratic ideas of what merits FAILURE-P, but it's
 131                 embarrassing to have to use it when bootstrapping
 132                 under SBCL!),
 133    * miscellaneous simple refactoring
 134         * belated renaming:
 135                 ** rename %PRIMITIVE to %VOP
 136                 ** A few hundred things named FN and FCN should be
 137                         named FUN
 138         * These days ANSI C has inline functions, so..
 139                 ** redo many cpp macros as inline functions:
 140                         HeaderValue, Pointerp, CEILING, ALIGNED_SIZE,
 141                         GET_FREE_POINTER, SET_FREE_POINTER,
 142                         GET_GC_TRIGGER, SET_GC_TRIGGER, GetBSP, SetBSP,
 143                         os_trunc_foo(), os_round_up_foo()
 144                 ** remove various avoid-evaluating-C-macro-arg-twice
 145                         cruft
 146   * Some work on conditions emitted by the system
 147         ** eliminate COMPILER-WARN and COMPILER-STYLE-WARN, which
 148                 were simply limited versions of WARN and STYLE-WARN.
 149         ** make STYLE-WARN parallel WARN more closely (by accepting
 150                 a condition type, which should be a subtype of
 151                 STYLE-WARNING, and initargs, as well as a format
 152                 string and format arguments for SIMPLE-STYLE-WARNING.
 153                 (WARN can also be used to signal STYLE-WARNINGs, but
 154                 STYLE-WARN helps to document the code)
 155         ** eliminate use of INHIBIT-WARNINGS by code emitted by the
 156                 system from user code.
 157         ** cause use of INHIBIT-WARNINGS to signal a STYLE-WARNING.
 158         ** eliminate use of INHIBIT-WARNINGS within the system
 159         ** deprecate INHIBIT-WARNINGS, causing its use to signal a
 160                 full WARNING.
 161         ** begin work on developing a class hierarchy of conditions
 162                 along semantic lines.
 163
 164 PCL INTEGRATION
 165
 166   AKA CLOS in cold init.
 167
 168 HIGH LEVEL SOCKET INTERFACE
 169
 170   Something slightly above the level of BSD sockets would be nice.
 171
 172 RPC INTERFACE
 173
 174   For talking with other processes.
 175
 176 CROSS PLATFORM GUI
 177
 178   Since this is a high priority we're waiting for PHP coders to
 179   offer their help to build a website about this.
 180
 181 BLOCK COMPILATION
 182
 183   You know, like CMUCL does.
 184
 185 (MOSTLY) PARALLEL GC
 186
 187   Several algorithms exist, even one would be nice.
 188
 189 INCREMENTAL GC
 190
 191   For those who need it.