X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=TODO;h=6c8d83ba9e4b4d7eeb3f90a5a5862e0c5a16d433;hb=HEAD;hp=e3a196448bd4efd066dd3e214afd66bc8a0c9ce7;hpb=5eb97830eca716fef626c6e12429c99c9b97e3c8;p=sbcl.git diff --git a/TODO b/TODO index e3a1964..6c8d83b 100644 --- a/TODO +++ b/TODO @@ -1,184 +1,184 @@ - 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: - The batch-related command line options for SBCL don't work - properly. - A small part of making them work properly is making sure that - verbose GC messages end up piped to error output. - Make sure that when the system dies due to an unhandled error - in batch mode, the error is printed successfully, whether - FINISH-OUTPUT or an extra newline or whatever is required. - Make sure that make.sh dies gracefully when one of the SBCLs - it's running dies with an error. -MUSING: - Actually, the ANSI *DEBUGGER-HOOK* variable might be a better - place to put the die-on-unhandled-error functionality. -FIX: - ?? -------------------------------------------------------------------------------- -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: - In order to make a well-behaved backtrace when a batch program - terminates abnormally, it should be limited in length. -FIX: - ?? Add a *DEBUG-BACKTRACE-COUNT* variable, initially set to 64, - to provide a default for the COUNT argument to BACKTRACE. -------------------------------------------------------------------------------- -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: - When cross-compiling host-byte-comp.lisp, I get bogus - warnings - caught STYLE-WARNING: - undefined function: %%DEFCONSTANT - caught STYLE-WARNING: - This function is undefined: - %%DEFCONSTANT -MUSING: - The best way to clean this up would be as a side-effect of - a larger cleanup, making all the %%DEFFOO stuff use EVAL-WHEN - instead of IR1 magic. - There's probably some way to do it with a quick local hack too. -FIX: - ?? -------------------------------------------------------------------------------- -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". -------------------------------------------------------------------------------- -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: - The :SB-TEST target feature should do something. -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. -------------------------------------------------------------------------------- -PROBLEM: - The hashing code is new and should be tested. -FIX: - ?? Enable the existing test code. -=============================================================================== -other known issues with no particular target date: - -user manual including, at a minimum, updated versions of the -CMU CL user manual information on the compiler and the alien -interface - -bugs listed on the man page - -more regression tests - -various bugs fixed in CMUCL since this code was forked off of it -ca. 19980801, since most of these haven't been fixed yet in SBCL - -byte compilation of appropriate parts of the system, so that the -system core isn't so big - -uninterning needed-only-at-init-time stuff after init is complete, -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. - -The eventual plan is for SBCL to bootstrap itself in two phases. In -the first phase, the cross-compilation host is any old ANSI Common -Lisp (not necessarily SBCL) and the cross-compiler won't handle some -optimizations because the code it uses to implement them is not -portable. In the second phase, the cross-compilation host will be -required to be a compatible version of SBCL, and the cross-compiler -will take advantage of that to implement all optimizations. The -current version of SBCL only knows how to do the first of those two -phases, with a fully-portable cross-compiler, so some optimizations -are not done. Probably the most important consequence of this is that -because the fully-portable cross-compiler isn't very smart about -dealing with immediate values which are of specialized array type -(e.g. (SIMPLE-ARRAY (UNSIGNED-BYTE 4) 1)) the system sometimes has to -use unnecessarily-general array types internally. - -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.