-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
147 lines (109 loc) · 5.11 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
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?
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.
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.
INHIBIT-WARNINGS really needs to go away.
WINDOWS
Needs love.
DARWIN
Needs love, particularly threads and exceptions/signals.
DRAGONFLY
Multithreading does not work. Possibly because of bug in mmap/munmap.
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
* 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.
(MOSTLY) PARALLEL GC
Several algorithms exist, even one would be nice.
INCREMENTAL GC
For those who need it.