I spent much of the day doing applications stuff with the current CVS version of SBCL. There were no unpleasant surprises. So far it looks as though I can actually release sbcl-0.7.0.
"Applications stuff" ended up being mostly ripping out my old nasty-and-becoming-nastier a-functor-is-a-macro implementation of ML-style functors and replacing them with a package-based implementation, where a functor is essentially a file full of code which, with help from some nicknaming and other hacks, maps domain packages onto a created package. So far it looks reasonably good: various rough edges, but none of them dangerously close to the tricky parts of the stuff I'm trying to express. And rough edges and all, the functor-based code seems substantially cleaner and closer to what I'm trying to express than either the ancestral "functor? whazzat?" OO-and-stuff code or the intermediate a-functor-is-a-macro code did.
Of course, ML does this better. Or mostly. Last year, when I was playing with this in ML, I did end up very frustrated with some natural-seeming stuff involving mutually recursive types. But certainly ML does the easy cases much better. And that's not necessarily a put down: it can be a real danger sign when my small programs already seem a little kludgy when I know I still need to scale them up. So I'm still somewhat nervous about the upcoming push to generalize the current code.
Before we get too much closer to the end of the line with Von Neumann architecture stuff, it would sure be nice if someone could put together a language which (1) did Lisp stuff, (2) shaded smoothly over into statically typed stuff like ML, and (3) didn't bog down on too many reasonable type relationships the way that ML did in my experiments late last year. Or, if its type inference logic did bog down, then having some way of being lifted out by suitable manual declarations.
Meanwhile, I haven't actually hit any real gotchas with my Lisp and duct tape approach, or even spotted them on the horizon. Maybe I'll be OK.
Not a bad day.