SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

I've tried to reorganize this into a hierarchy of things that are already close to done or will likely be done soon, things that might be a focus to work on after 0.9, and things that are a bit broader in scope or maybe not necessary for 1.0. Feel free to reorganize this; I certainly don't set the priorities for anybody but myself - Brian Mastenbrook

Things which might already be done, or are close to done:

• threads, reliable - Timeouts, interaction between threads and serve-event is broken, at least as seen by Araneida (I suspect TRT is an fd-streams rewrite/expunge/similar).

• Debugger?:
  • The interface is slightly nonobvious. Debugger command-line interface seems less useful now that SLIME is widely used?
  • XEPs in the backtrace - still there, I think, and there's that peculiar 'number of arguments displayed' error as well.
  • displaying local variable values (mostly a question of figuring out what compiler options you should have used)
  • The API needs thinking about: see Allegro debugger API.
  • Breakpoint commands could be reinstated, based on the :break option to TRACE.
  • I'm really not quite sure what specific complaints people have about the debugger itself. The API needs some TLC, which hopefully will take the form of a stable enough API that something like SWANK can depend on. see below

• FFI: callbacks, working fwrappers, linkage-table on alpha.

• Christophe says that somebody needs to fix the pretty-printer. How many bugs are we seeing from this? I thought the current number of ANSI bugs was under 20, and not all of those from the printer. We see probably about 50 failures from Paul's test suite currently: there is only one printer-related bug, but it's a big one: circularity detection goes missing even when *PRINT-CIRCLE* is non-NIL in certain circumstances, which lead to stack exhaustion or heap exhaustion or other Generally Bad things. The other bugs floating around are currently fairly straightforward, or else are points of relative contention between Paul Dietz?'s interpretation of the specification and that of those of us who track the test suite.

Things which might be a focus in the 0.9 series:

• Fast user extensible streams, and a threadsafe serve-event replacement. The last is something I (Brian Mastenbrook) intend to work on, with the hope of providing controllable re-entrancy and maybe even a way of specifying what function to use as a select-alike (so users can plug in kqueues or GUI event-wait functions).

• The Manual - converted to TeXinfo; reorganization is well underway. This seems hopeful. New stuff that needs to be written: documentation for rest of the contribs, copying the second section of AMOP & adding SBCL specific annotations (yes, this is legal -- the book gives explicit permission), the missing bits from Efficiency chapter (adapt from CMUCL manual), documentation on various compiler policies in a single place (maybe partially autogenerated?).

• If we're going to be copying in AMOP, it might be good to support more of AMOP than we currently do. See sbcl-devel and BUGS passim.

• useful hooks for alternative UIs - being addressed as part of SLIME. It would be nice if SLIME for SBCL 1.0 contained no references to internal symbols of the SBCL implementation packages (encompassing both unexported symbols and nominally-exported symbols of internal packages). This should IMO include unification of repl-like interfaces (REPL, debugger, inspect), so that they share the same mechanism and are easier to extend and hook into --Nikodemus These APIs should of course be documented in The Manual as we go along

• TRACE and PROFILE? aren't entirely well-behaved - not when TRACEing CL symbols, which might be Not Supported Anyway. This doesn't feel like a showstopper to me. (I think the problem is with the interaction between TRACE and PROFILE, not necessarily the individual functions themselves.) I'd really like to see this fixed (even if by just preventing tracing of certain functions), since it makes a rather bad impression on the user to have SBCL crash because you traced something... --nikodemus

  I think the current goal is to rewrite TRACE in terms of fwrappers, which will reduce the amount of maintenence that needs to be done on things using breakpoints.

• Some way of deploying patches and downloading them to an installed SBCL would be nice as well. asdf-install paves the way for this; possibly some small hack of this code could be used to download patches from the SBCL site and have SBCL load them on boot (ala LispWorks).

• Some way of making sure that we do not break FASL compatibility would be nice. Since radical redesigns of the FASL format to make it more robust in the face of eg. function interface changes sound unlikely to happen, a test suite composed of large applications seems like the best bet. When the format does change, can we provide automatic conversion for some cases at least? Just a thought: one class of changes that affect fasl-compatibility are signatures of internal functions appearing in compiled code: maybe we could check for signature-compatibility programmatically.

  If we think this is a big issue, the easiest way to address it might be to turn every macro with an implicit progn like (SB-EXT:WITH-FOO (ARG1 ARG2) BODY ...) into (SB-INT::%WITH-FOO (LIST ARG1 ARG2) (LAMBDA () BODY)); this prevents leakage of function arguments, but at a cost of efficiency. Is this worth it? PCL is a mess of macros with these possible issues.

• These previous two points touch on a broader discussion about how to maintain the 1.0 branch - what bugs will we be fixing on the branch? I think if we agree to stick to means of bug fixes that don't affect FASL compatibility, the previous point isn't very relevant; I can't see that we'll be wanting to maintain FASL compatibility between major feature-adding revisions.

• Generally speaking ugly APIs should be deprecated in favor of replacements, as happened with LOAD-FOREIGN. This may not be possible for every ugly API in the system, however. Isn't this something we do as we go along? Except that the point about 1.0, at least in my interpretation, is that it implies a modicum of support for what's currently there: at least through 1.1, 1.2, etc.; 2.0 may be another matter. Having to support an ugly, irredeemable API doesn't seem like fun; nor does explaining to our users that 2.0 has come out 3 months after 1.0 and would everyone please upgrade? Therefore, bad APIs and stuff have to come out before 1.0.

Things which might not be necessary for 1.0 (feel free to comment or disagree)

• Block compilation

• Remove MAYBE-INLINE? - Has this been worked on yet?

• maybe gengc on non-x86 - doesn't seem like a showstopper to me (Brian Mastenbrook)

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively