I went through a similar though process recently when doing some language work. Another slightly more traditional representation down this (slightly reductioni

I went through a similar though process recently when doing some language work. Another slightly more traditional representation down this (slightly reductionist) track is to use two symbols - TRUE and FALSE. Then numbers are simply lists of these symbols (i.e. you use lists to represent the bytes/bits/whatever). I say reductionist, but it's still tempting as it increases how orthogonal your language is (which goes towards the simplicity/elegance/scale angle discussed in this article). You can apply similar logic to other firmly-established types such as strings - which can be lists, but are generally more efficient as char* arrays. In the end, I decided that whilst this approach was great from a purist perspective, I was actually working against my target platform. The reality is that the CPUs I'd be ever likely to target are designed to work with numbers. So I made the compromise not to rail against that (Whereas the LISP machine pictured in the article is almost a vision of another, alternative reality). One alternative I've considered is putting in lazy evaluation. Things will work as numbers, but as soon as you call a list operation, it promotes it to the list form... Although to be honest it hasn't come up yet, which is somewhat of a surprise, so I'm not sure if I'll ever get around to that.