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.
No offense, but making surreal numbers in code seems a bit pointless.
Yes, both mathematics and programming, like any other user interfaces, are built on abstractions, and yes, we benefit by making those abstractions elegant: namely, few, small, orthogonal, and flexible (in the words of the article, "Elegance consists of building something out of a small core of representations that scale well. It is not enough that they be simple, the complexity of what you build must not grow uncontrollably as you try to solve bigger and more complex problems."), but surreal numbers are much easier to understand without looking at a bunch of extra verbose syntax of a programming language. There may be some value in implementing such a thing personally if you're trying to make sure you understand what surreal numbers really do and how they really work, but reading someone else's implementation just gets in the way. I definitely recommend Conway's book. It's loads of fun.
Incidentally, just about every other user interface also benefits from adopting these "elegance" principles (GUIs, hand tools, political systems, etc.). They are among the essential axioms of design, and any designer should keep them always in mind. I think I like the version in the "Zen of Python" best of any wording I've seen.
> No offense, but making surreal numbers in code seems a bit pointless... There may be some value in implementing such a thing personally if you're trying to make sure you understand what surreal numbers really do and how they really work, but reading someone else's implementation just gets in the way.
I'm not offended in the least.
Above and beyond any reasons I may have for writing such code myself, putting code into my essays serves a very important purpose: It makes a personal statement about the balance between code and ideas. There are already excellent sources of information about mathematics and programming languages. For example, the post links to both Mark Chu-Carroll's blog and Paul Graham's essay.
I agree fully that my own writing is far less useful than either of these sources for learning about mathematics or about the design of programming languages. But I must soldier on trying to make my own personal point, and in this case the point includes a certain amount of code.
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.