Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

[57328d]: TODO Maximize Restore History

Download this file

TODO    173 lines (162 with data), 8.2 kB

for early 0.7.x:

* urgent EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup:
	** made inlining DEFUN inside MACROLET work again
	** (also, while working on INLINE anyway, it might be easy
		to flush the old MAYBE-INLINE cruft entirely, 
		including e.g. on the man page)
* test file reworking
	** non-x86 ports now pass irrat.pure.lisp
	** sparc and ppc now pass bit-vector.impure-cload.lisp
* faster bootstrapping (both make.sh and slam.sh)
	** added mechanisms for automatically finding dead code, and
		used them to remove dead code
	** moved stuff from warm init into cold init where possible
		(so that slam.sh will run faster and also just because
		ideally everything would be in cold init)
	** profiled and tweaked
* fixed (TRACE :REPORT PROFILE ...) interface to profiling
* more EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup:
	** made %COMPILE understand magicality of DEFUN FOO
		w.r.t. e.g. preexisting inlineness of FOO
	** used %COMPILE where COMPILE-TOP-LEVEL used to be used
	** removed now-redundant COMPILE-TOP-LEVEL and 
		FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
	** (ideally, but perhaps too hard, given what I've discovered
		about the godawful internals of function debug names):
		made FUNCTION-NAME logic work on closures, so that
		various public functions like CL:PACKAGEP which
		are now implemented as closures (because
		they're structure slot accessors) won't be so
		nasty in the debugger
* outstanding embarrassments
	** cut-and-pasted DEF-BOOLEAN-ATTRIBUTE (maybe easier to fix
		now that EVAL-WHEN works correctly..)
	** :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!),
	** weird double-loading (first in GENESIS, then in warm init)
		of src/assembly/target/*.lisp stuff, and the associated
		weirdness of the half-baked state (compiler almost but
		not quite ready for prime time..) of the system after
		cold init
* fixups now feasible because of pre7 changes
	** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE)
* miscellaneous simple refactoring
	* belated renaming:
		** renamed %PRIMITIVE to %VOP
	* These days ANSI C has inline functions, so..
		** redid 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()
		** removed various avoid-evaluating-C-macro-arg-twice
			cruft
* Either get rid of or at least rework the fdefinition/encapsulation
	system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
	(FDEFINITION 'FOO).
=======================================================================
for 0.9:

* refactored in preparation for moving CLOS into cold init and merging
	SB-PCL:FOO with CL:FOO (for FOO=CLASS, FOO=CLASS-OF, etc.)
	** systematized support for MOP (new regression tests, maybe
		new SB-MOP package..) to try to make sure things don't
		get mislaid in the upcoming CLOS restructuring
	** extracted type system from SB-KERNEL into new SB-TYPE
		package
	** reimplemented GENERIC-FUNCTION as a primitive object (or
		maybe made SB-MOP:FUNCALLABLE-STANDARD-OBJECT the
		primitive object, and then let GENERIC-FUNCTIONs
		inherit from that) instead of structures with
		:ALTERNATE-METACLASS and funcallableness. Now
		FUNCALLABLE-INSTANCE can go away. (And now the new
		funcallable primitive objects need to go into
		collections like *FUN-HEADER-WIDETAGS* where
		FUNCALLABLE-INSTANCE objects used to be.)
	** reimplemented CONDITIONs as primitive objects instead of 
		structures with :ALTERNATE-METACLASS. Now (between
		this and the change to GENERIC-FUNCTIONs)
		DEFSTRUCT :ALTERNATE-METACLASS can go away.
	** (maybe) Now INSTANCE_POINTER_LOWTAG can become just
		STRUCTURE_POINTER_LOWTAG, and the concept of
		SB-KERNEL:INSTANCE (including INSTANCEP, 
		(SPECIFIER-TYPE 'INSTANCE), etc.) can go away.
* moved CLOS into cold init, in order to allow CLOS to be used in the
	implementation of the core system (e.g. the type system and the
	compiler) and in order to support merger of CL:CLASS with 
	SB-PCL:CLASS
* (maybe) eliminated warm init altogether in favor of cold init
* (maybe, especially if warm init can be eliminated) rationalized
	the build process, fixing miscellaneous pre-0.5.0 stuff that's
	transparently not the right thing
	** removed separate build directories, now just building in 
		place with .sbclcoldfasl extensions
* (maybe) more refactoring in preparation for merging SB-PCL:FOO
	into CL:FOO: reimplemented type system OO dispatch
	(!DEFINE-TYPE-METHOD, etc.) in terms of CLOS OO dispatch
* merged SB-PCL:FOO into CL:FOO (and similarly CLASS-OF, etc.)
* added some automatic tests for basic binary compatibility, in hopes
	that it might be practical to maintain binary compatibility
	between minor maintenance releases on the stable branch (but no
	promises, sorry, since I've never tried to do this before, and 
	have no idea how much of a pain this'll be)
========================================================================
for 1.0 (fixes of lower priority which I'd nonetheless be embarrassed
to leave unfixed in 1.0):
* all too many BUGS entries and FIXMEs
=======================================================================
other priorities, no particular time:

* bug fixes, especially really annoying bugs (ANSI or not) and any
	ANSI bugs (i.e. not just bugs in extras like the debugger or
	"declarations are assertions", but violations of the standard)
* better communication with the outside world (scratching WHN's
	personal itch): I don't want socket-level stuff so much as I
	want RPC-level or higher (CORBA?) interfaces and (possibly
	through RPC or CORBA) GUI support
=======================================================================
important but out of scope (for WHN, anyway: Patches from other people
are still welcome!) until after 1.0:
	* DYNAMIC-EXTENT
	* sadly deteriorated support for ANSI-style block compilation
		(static linking of DEFUNs within a single file or 
		WITH-COMPILATION-UNIT)
	* various GC issues (exuberant cut-and-paste coding,
		possibly dangerously over-conservative handling
		of neighbors of function objects, general GC efficiency)
	* package issues other than SB!TYPE, SB!MOP, and dead exported
		symbols
	* Any systematic effort to fix compiler consistency checks is
		out of scope. (However, it still might be possible to
		determine that some or all of them are hopelessly stale
		and delete them.)
=======================================================================
other known issues with no particular target date:

bugs listed on the man page

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.)
=======================================================================
"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