> Paul notes that strings and lists really should just be represented as lists and the compiler should efficiently handle lists of characters as a special case.

The sort of operations commonly done on strings only have a small overlap with list operations, though. I'm all for orthogonality in a language when it's practical, but I'm not sure that one is a good trade-off.

Erlang does that, and aside from space issues (on 64-bit, a linked list of character code ints means 16 bytes per char, due to alignment), it's kind of awkward. While using pattern matching on individual chars is nice, in those cases it probably makes more sense to tokenize the strings into atoms/tuples via REs, and then pattern-match on those instead. Binaries can also be used as pseudo-strings, but to me it feels like two half-solutions. (And its shell's printing a list of ints as chars when they're printable 7-bit ASCII characters is a bit odd.) Having atoms (AKA symbols) helps, though.

Incidentally, Lua's strings are all immutable atoms. That's practical most of the time, but occasionally a major liability. Lua has the obvious option of just using a different string implementation via userdata when it's a problem, though, so it can make such a daring trade-off.

Of course, just saving strings as arrays with a \0 at the end is also pretty brittle.