-for late 0.7.x:
+for early 0.8.x:
* test file reworking
** non-x86 ports now pass irrat.pure.lisp
* fixups now feasible because of pre7 changes
** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE,
including e.g. on the man page)
+ ** (maybe) allow INLINE of a recursive function, so that the
+ body is inlined once
* miscellaneous simple refactoring
* belated renaming:
** renamed %PRIMITIVE to %VOP
** A few hundred things named FN and FCN should be
- named FUN (but maybe not while dan_b is
- working on a threads branch and drichards is
+ named FUN (but maybe not while drichards is
working on a Windows port).
* These days ANSI C has inline functions, so..
** redid many cpp macros as inline functions:
* Either get rid of or at least rework the fdefinition/encapsulation
system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
(FDEFINITION 'FOO).
+* Make the system sources understandable to the system, so that
+ searching for sources doesn't error out quite so often
+ (e.g. in error handlers)
+ ** provided a suitable readtable for reading in the source
+ files when necessary, and a mechanism for activating
+ this readtable rather than the standard one.
+* Some work on conditions emitted by the system
+ ** eliminated COMPILER-WARN and COMPILER-STYLE-WARN, which
+ were simply limited versions of WARN and STYLE-WARN.
+ ** made STYLE-WARN parallel WARN more closely (by accepting
+ a condition type, which should be a subtype of
+ STYLE-WARNING, and initargs, as well as a format
+ string and format arguments for SIMPLE-STYLE-WARNING.
+ (WARN can also be used to signal STYLE-WARNINGs, but
+ STYLE-WARN helps to document the code)
+ ** eliminated use of INHIBIT-WARNINGS by code emitted by the
+ system from user code.
+ ** caused use of INHIBIT-WARNINGS to signal a STYLE-WARNING.
+ ** eliminated use of INHIBIT-WARNINGS within the system
+ ** deprecated INHIBIT-WARNINGS, causing its use to signal a
+ full WARNING.
+ ** began work on developing a class hierarchy of conditions
+ along semantic lines.
+ ** annotated conditions emitted by the system to have
+ references to documentation where applicable, so that
+ users can easily find an explanation for the
+ conditions they're seeing.
+
=======================================================================
for 0.9:
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
+* Especially when ldb is not compiled in, the default "assertion failed"
+ behaviour in many parts of the runtime is unfriendly. It may
+ be appropriate to look at some of these and see if they can be
+ handled in some less abrupt way than aborting
=======================================================================
important but out of scope (for WHN, anyway: Patches from other people
are still welcome!) until after 1.0: