Versus Common Lisp

While I have no specific goal (nor resources, probably) to implement the full Common Lisp specification, SLip is closer to Common Lisp than to other dialects. This page lists some fundamental differences.

Strings are immutable

Since JS strings are immutable, so are SLip strings. At this time they cannot be treated as a sequence of characters, so sequence functions won't work on strings. I could fix this by boxing strings in a custom object, but I think that would reduce performance for no practical benefit.

As a consequence, EQ will return T for two strings that have the exact same contents (I had to modify some of the tests to account for this). Additionally, EQ and EQL are identical — there is no case where one could return true and the other false.

Eval-always

As mentioned in implementation notes, while compiling a piece of code all toplevel expressions are evaluated in sequence.

No exact arithmetic

Integer and floating point precision is as good as your browser can do. There are no rational and no complex numbers.

No reader customization

For the time being you can't customize the reader. Even if that will be possible at some point, the API will probably be different from Common Lisp's.

No “debugger”

Debugging, for now, is painful. There's no step-by-step debugger, or stack frame inspector.

Lots more...

I'm pretty sure there are a lot more things we're missing, but most of them could fall in the “library” section. For example we don't have a pretty printer — correction 2025, we now have one; a LOOP macro - correction 2025, LOOP has been implemented; and the format function is incomplete (though still quite useful). But most of this missing functionality can be written in SLip itself, so it's less essential.