1[ This is -*-Indented-Text-*- ] 2 3This list was written by John Harper, the original author of Librep, 4but the current Sawfish community has little hope to accomplish any 5of them. 6 7TODO list for librep 8******************** 9 10Bugs are marked !, things that should be done soon are marked +, 11and more long-term ideas are marked - 12 13 14Outstanding bugs 15================ 16 17 ! uses setlocale("LC_NUMERIC", "C") to make floating point I/O work, 18 need to reimplement this locally 19 20 [ this is only done temporarily now, but rep-gtk still has some 21 instances that can't be removed until librep 0.14 I guess.. ] 22 23 ! modules with `(set-binds)' config shouldn't inline constants? 24 25 ! #!key params can't be inlined by the compiler 26 27 ! non-top-level compiled defvar's aren't quite right 28 29 ! the first level lookup of foo#bar isn't cached 30 31 ! interfaces aren't re-parsed when modules are reloaded 32 33 ! environment of macro expanders is not consistent 34 35 interpreted code closes macros in the usual lexical environment, 36 the compiler closes them in the *root-strcucture* since the 37 lexical environment of the compiled file doesn't exist 38 39 Xerox scheme closes all macros in the `initial environment', this 40 would provide consistency, but would break existing code 41 42 ! macro memoization loses 43 44 e.g. if same (eq) expression is expanded in different structures 45 46 OTOH, there is little or no chance of this ever happening 47 48 ! doesn't handle NaN or Inf in floats properly (at all) 49 50 ! if load can't find the file, its error message is confusing 51 (especially if the named file does exist, but no suffixed file 52 exists) 53 54 ! non-fixnum numbers can't be dumped / dump totally broken re: modules 55 56 ! it's legal to do (set foo 42) where the contents of foo has a 57 lexical binding 58 59 this breaks: (let ((var 'loop)) 60 (let loop ((foo t)) 61 (set var print) 62 (loop foo))) 63 64 + document in manual: current-utime, new read syntaxes 65 66 + deprecated: 67 68 * 0xNN and 0NN integer syntaxes [0.13+] 69 * &optional and &rest (replaced by #!optional and #!rest) [0.13+] 70 71 + Closure scope 72 73 Only top level `define's are correct in closures; others are 74 defined in the module. 75 76General programming tasks: 77========================== 78 79 + allow the random number generator to be seeded with a given value 80 81 + comparison of datums currently compares type id and contents 82 83 should be defined by programmer, e.g.: 84 85 (define-datum-comparer ID FUN) 86 87 by analogy with define-datum-discloser 88 89 (but do callers of rep_value_cmp () assume that it may GC?) 90 91 + avoid spurious init-bind and unbind instructions 92 93 (generated when lexical bindings aren't heap allocated) 94 95 + add restricted load to gaol? (same directory only?) 96 97 + %make-structure shouldn't map names to structures itself 98 99 it's done this way to allow mutually recursive structures (debatable 100 itself) but really %make-structure should just create the thing 101 (with an optional name for printing) 102 103 - allow ML-like functors (parameterized modules) 104 105 the basic support is there. Can do: 106 107 (define (my-functor x) 108 (structure (export foo) (open rep) 109 (define (foo y) (+ x y)))) 110 111 but there's currently no clean way to import the first-class 112 structure (without resorting to open-structures) 113 114 I think the way is to require the functor to implement a named 115 interface which is specified in the module signature: 116 117 (define-structure foo 118 (open rep 119 (functor (my-functor x) some-interface)) 120 ... 121 122 `(my-functor x) would get evaluated in the environment containing 123 the define-structure form? Or in the environment created up to that 124 point? 125 126 The named-interface trick could also be useful for importing normal 127 modules (to avoid having to load them at compile time) 128 129 [ I have a first-stab at this, needs compiler support.. ] 130 131 - add a facility for dumping a set of structures, for later reloading 132 133 - move the gtk-independent parts of the rep-gtk glue generator and 134 support code to librep 135 136 [ I've rewritten the glue-code generator in an oo style so that it 137 can be easily extended. Need to rewrite the runtime support. Will do 138 this in time for GTK 2.0 ] 139 140 - add defadvice (port from elisp? other implementations?) 141 142 - Compiler could annotate output files with their dependences 143 144 - I/O shouldn't block all threads 145 146 wait_for_input () already groks threads, so I think the only problem 147 is the use of stdio/fd functions. How does stdio handle streams that 148 have been set non-blocking? Maybe reimplement basic stdio? 149 150 (there is now support for waking threads via polling) 151 152 [ I have a patch that adds support for threads to be woken when 153 one of a set of fds is available for writing and reading. It 154 also has a blocking I/O function that suspends the thread while 155 it blocks.. ] 156 157 - add regression tests 158 159 [ partially done, there is a test framework now, but only a couple 160 of modules define tests ] 161 162 - the gc sucks 163 164 is it possible to add a good (generational?) gc? 165 166 could sweeping be sped up by prefetching cache lines? 167 168 do lazy sweeping of block-allocated objects? (problem with cons mark bit?) 169 170 do mostly non-recursive marking? (mark stack) 171 172 [ tried this -- marginally slower than current method ] 173 174 - remove special forms (replacing them with macros) where both 175 possible and desirable 176 177 The current (July 2000) list of special forms is: 178 179 cond %define defvar lambda progn quote setq 180 181 - most subrs can't be called tail recursively (apply is special-cased) 182 183 - add a hygienic macro facility 184 185 this may be overkill? capture of introduced bindings can be avoided 186 using gensyms, capture of introduced free variables could be avoided 187 by introducing a way of tagging variable references with the 188 structure they need to be dereferenced in. 189 190 [ I have an experimental low-level hygienic macro implementation, 191 but it's a long way from being useful ] 192 193 - do JIT compilation of bytecode where profitable 194 195 there's now GNU lightning, a VCODE-like system, using C macros to do 196 portable runtime code generation 197 198 Only do this for _heavily_ used bytecode subrs. Measure this by 199 adding an extra vector slot, and counting the number of vm 200 instructions executed (and dividing by the length of the 201 code-string?) 202 203 Another option is to generate direct-threaded code from the bytecode 204 (and cache it). I have an attempt at this but it needs either (1) an 205 extra pass to detect labels, or (2) to maintain a strict mapping 206 between bytecode addresses and direct-code addresses 207 208 There's an interesting paper about automatically generating meta 209 instructions to suit individual instruction sequences, PLDI 98 or 210 something (check citeseer for it). Applied with reasonable success 211 to Caml interpreter 212 213 - Optimize compilation of case statements 214 215 1. handle constant keys 216 217 2. optimize the search (binary search if all clauses have same type 218 and are orderable?) 219 220 - Add more backends for accessing remote files 221 222 Make remote-rcp work properly, and add others (ssh, http, ..?) 223 224 - Make the compiler optimise its output 225 226 now the lisp is mostly lexically scoped, there should be much 227 more potential for aggressive optimisation 228 229 230Manual tasks: 231============= 232 233 + Document: variables `error-mode', `interrupt-mode', `idle-hook', 234 and `program-name' 235 236 + Document the internals (i.e. the C interface) 237