TODO

   1 planned incompatible changes in 0.8.x:
   2   * (not done yet, but planned:) When the profiling interface settles
   3     down, it might impact TRACE. They both encapsulate functions, and
   4     it's not clear yet how e.g. UNPROFILE will interact with TRACE
   5     and UNTRACE. (This shouldn't matter, though, unless you are using
   6     profiling. If you never profile anything, TRACE should continue to
   7     behave as before.)
   8   * (not done yet, but planned:) Inlining can now be controlled the
   9     ANSI way, without MAYBE-INLINE, since the idiom
  10         (DECLAIM (INLINE FOO))
  11         (DEFUN FOO (..) ..)
  12         (DECLAIM (NOTINLINE FOO))
  13         (DEFUN BAR (..) (FOO ..))
  14         (DEFUN BLETCH (..) (DECLARE (INLINE FOO)) (FOO ..))
  15     now does what ANSI says it should. The CMU-CL-style
  16     SB-EXT:MAYBE-INLINE declaration is now deprecated and ignored.
  17
  18 for early 0.8.x:
  19
  20 * test file reworking
  21         ** ports with less than 256Mb of heap (sparc, ppc and mips)
  22                 now don't fail bit-vector.impure-cload.lisp
  23 * faster bootstrapping (both make.sh and slam.sh)
  24         ** added mechanisms for automatically finding dead code, and
  25                 used them to remove dead code
  26         ** moved stuff from warm init into cold init where possible
  27                 (so that slam.sh will run faster and also just because
  28                 ideally everything would be in cold init)
  29         ** profiled and tweaked
  30 * fixed (TRACE :REPORT PROFILE ...) interface to profiling
  31 * more EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup:
  32         ** made %COMPILE understand magicality of DEFUN FOO
  33                 w.r.t. e.g. preexisting inlineness of FOO
  34         ** used %COMPILE where COMPILE-TOP-LEVEL used to be used
  35         ** removed now-redundant COMPILE-TOP-LEVEL and
  36                 FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
  37         ** (ideally, but perhaps too hard, given what I've discovered
  38                 about the godawful internals of function debug names):
  39                 made FUNCTION-NAME logic work on closures, so that
  40                 various public functions like CL:PACKAGEP which
  41                 are now implemented as closures (because
  42                 they're structure slot accessors) won't be so
  43                 nasty in the debugger
  44 * outstanding embarrassments
  45         ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's
  46                 reasonable to support this as a crutch when initially
  47                 bootstrapping from balky xc hosts with their own
  48                 idiosyncratic ideas of what merits FAILURE-P, but it's
  49                 embarrassing to have to use it when bootstrapping
  50                 under SBCL!),
  51 * fixups now feasible because of pre7 changes
  52         ** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE,
  53                 including e.g. on the man page)
  54         ** (maybe) allow INLINE of a recursive function, so that the
  55                 body is inlined once
  56 * miscellaneous simple refactoring
  57         * belated renaming:
  58                 ** renamed %PRIMITIVE to %VOP
  59                 ** A few hundred things named FN and FCN should be
  60                         named FUN (but maybe not while drichards is
  61                         working on a Windows port).
  62         * These days ANSI C has inline functions, so..
  63                 ** redid many cpp macros as inline functions:
  64                         HeaderValue, Pointerp, CEILING, ALIGNED_SIZE,
  65                         GET_FREE_POINTER, SET_FREE_POINTER,
  66                         GET_GC_TRIGGER, SET_GC_TRIGGER, GetBSP, SetBSP,
  67                         os_trunc_foo(), os_round_up_foo()
  68                 ** removed various avoid-evaluating-C-macro-arg-twice
  69                         cruft
  70 * Either get rid of or at least rework the fdefinition/encapsulation
  71         system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
  72         (FDEFINITION 'FOO).
  73 * Make the system sources understandable to the system, so that
  74         searching for sources doesn't error out quite so often
  75         (e.g. in error handlers)
  76         ** provided a suitable readtable for reading in the source
  77                 files when necessary, and a mechanism for activating
  78                 this readtable rather than the standard one.
  79 * Some work on conditions emitted by the system
  80         ** eliminated COMPILER-WARN and COMPILER-STYLE-WARN, which
  81                 were simply limited versions of WARN and STYLE-WARN.
  82         ** made STYLE-WARN parallel WARN more closely (by accepting
  83                 a condition type, which should be a subtype of
  84                 STYLE-WARNING, and initargs, as well as a format
  85                 string and format arguments for SIMPLE-STYLE-WARNING.
  86                 (WARN can also be used to signal STYLE-WARNINGs, but
  87                 STYLE-WARN helps to document the code)
  88         ** eliminated use of INHIBIT-WARNINGS by code emitted by the
  89                 system from user code.
  90         ** caused use of INHIBIT-WARNINGS to signal a STYLE-WARNING.
  91         ** eliminated use of INHIBIT-WARNINGS within the system
  92         ** deprecated INHIBIT-WARNINGS, causing its use to signal a
  93                 full WARNING.
  94         ** began work on developing a class hierarchy of conditions
  95                 along semantic lines.
  96         ** annotated conditions emitted by the system to have
  97                 references to documentation where applicable, so that
  98                 users can easily find an explanation for the
  99                 conditions they're seeing.
 100
 101 =======================================================================
 102 for 0.9:
 103
 104 [ note: much of the below refers to preparation for merging SB-PCL:FOO
 105   and CL:FOO.  However, it turned out to be surprisingly
 106   straightforward to do this notional end goal without doing many of
 107   the preparatory operations.  That doesn't mean that plenty of the
 108   goals below aren't worthwhile, but the motivation is somewhat
 109   different. ]
 110
 111 * refactored in preparation for moving CLOS into cold init and merging
 112         SB-PCL:FOO with CL:FOO (for FOO=CLASS, FOO=CLASS-OF, etc.)
 113         ** systematized support for MOP (more regression tests, maybe)
 114                 to try to make sure things don't get mislaid in the
 115                 upcoming CLOS restructuring
 116         ** extracted type system (and maybe CLASSOIDs) from SB-KERNEL
 117                 into new SB-TYPE package
 118         ** reimplemented GENERIC-FUNCTION as a primitive object (or
 119                 maybe made SB-MOP:FUNCALLABLE-STANDARD-OBJECT the
 120                 primitive object, and then let GENERIC-FUNCTIONs
 121                 inherit from that) instead of structures with
 122                 :ALTERNATE-METACLASS and funcallableness. Now
 123                 FUNCALLABLE-INSTANCE can go away. (And now the new
 124                 funcallable primitive objects need to go into
 125                 collections like *FUN-HEADER-WIDETAGS* where
 126                 FUNCALLABLE-INSTANCE objects used to be.)
 127         ** reimplemented CONDITIONs as primitive objects instead of
 128                 structures with :ALTERNATE-METACLASS. Now (between
 129                 this and the change to GENERIC-FUNCTIONs)
 130                 DEFSTRUCT :ALTERNATE-METACLASS can go away.
 131         ** (maybe) Now INSTANCE_POINTER_LOWTAG can become just
 132                 STRUCTURE_POINTER_LOWTAG, and the concept of
 133                 SB-KERNEL:INSTANCE (including INSTANCEP,
 134                 (SPECIFIER-TYPE 'INSTANCE), etc.) can go away.
 135 * moved CLOS into cold init, in order to allow CLOS to be used in the
 136         implementation of the core system (e.g. the type system and the
 137         compiler) and in order to support merger of CL:CLASS with
 138         SB-PCL:CLASS
 139 * (maybe) eliminated warm init altogether in favor of cold init
 140 * (maybe, especially if warm init can be eliminated) rationalized
 141         the build process, fixing miscellaneous pre-0.5.0 stuff that's
 142         transparently not the right thing
 143         ** removed separate build directories, now just building in
 144                 place with .sbclcoldfasl extensions
 145 * (maybe) more refactoring in preparation for merging SB-PCL:FOO
 146         into CL:FOO: reimplemented type system OO dispatch
 147         (!DEFINE-TYPE-METHOD, etc.) in terms of CLOS OO dispatch
 148 * added some automatic tests for basic binary compatibility, in hopes
 149         that it might be practical to maintain binary compatibility
 150         between minor maintenance releases on the stable branch (but no
 151         promises, sorry, since I've never tried to do this before, and
 152         have no idea how much of a pain this'll be)
 153 ========================================================================
 154 for 1.0 (fixes of lower priority which I'd nonetheless be embarrassed
 155 to leave unfixed in 1.0):
 156 * all too many BUGS entries and FIXMEs
 157 =======================================================================
 158 other priorities, no particular time:
 159
 160 * bug fixes, especially really annoying bugs (ANSI or not) and any
 161         ANSI bugs (i.e. not just bugs in extras like the debugger or
 162         "declarations are assertions", but violations of the standard)
 163 * better communication with the outside world (scratching WHN's
 164         personal itch): I don't want socket-level stuff so much as I
 165         want RPC-level or higher (CORBA?) interfaces and (possibly
 166         through RPC or CORBA) GUI support
 167 * Especially when ldb is not compiled in, the default "assertion failed"
 168         behaviour in many parts of the runtime is unfriendly.  It may
 169         be appropriate to look at some of these and see if they can be
 170         handled in some less abrupt way than aborting
 171 =======================================================================
 172 important but out of scope (for WHN, anyway: Patches from other people
 173 are still welcome!) until after 1.0:
 174         * DYNAMIC-EXTENT
 175         * sadly deteriorated support for ANSI-style block compilation
 176                 (static linking of DEFUNs within a single file or
 177                 WITH-COMPILATION-UNIT)
 178         * various GC issues (exuberant cut-and-paste coding,
 179                 possibly dangerously over-conservative handling
 180                 of neighbors of function objects, general GC efficiency)
 181         * package issues other than SB!TYPE, SB!MOP, and dead exported
 182                 symbols
 183         * Any systematic effort to fix compiler consistency checks is
 184                 out of scope. (However, it still might be possible to
 185                 determine that some or all of them are hopelessly stale
 186                 and delete them.)
 187 =======================================================================
 188 other known issues with no particular target date:
 189
 190 bugs listed on the man page
 191
 192 hundreds of FIXME notes in the sources from WHN
 193
 194 various other unfinished business from CMU CL and before, marked with
 195   "XX" or "XXX" or "###" or "***" or "???" or "pfw" or "@@@@" or "zzzzz"
 196 or probably also other codes that I haven't noticed or have forgotten.
 197
 198 (Things marked as KLUDGE are in general things which are ugly or
 199 confusing, but that, for whatever reason, may stay that way
 200 indefinitely.)
 201 =======================================================================
 202 "There's nothing an agnostic can't do as long as he doesn't know
 203 whether he believes in anything or not."
 204   -- Monty Python.
 205
 206 "God grant me serenity to accept the code I cannot change, courage to
 207 change the code I can, and wisdom to know the difference."
 208   -- Erik Naggum
 209
 210 "Accumulation of half-understood design decisions eventually chokes a
 211 program as a water weed chokes a canal. By refactoring you can ensure
 212 that your full understanding of how the program should be designed is
 213 always reflected in the program. As a water weed quickly spreads its
 214 tendrils, partially understood design decisions quickly spread their
 215 effects throughout your program. No one or two or even ten individual
 216 actions will be enough to eradicate the problem."
 217   -- Martin Fowler, in _Refactoring: Improving the Design of Existing
 218      Code_, p. 360
 219
 220 "I wish I didn't know now what I didn't know then."
 221   -- Bob Seger