"Axioms" has a nice, mathy ring of solidity to it, but I'm pretty sure that, along with the axioms you are analyzing there are others you are barely thinking about but which also form the foundation of Arc. For example, the notion of code and data being the same in Lisp: strings of text. Is that an axiom? That's certainly one of the keys to the unusual power and flexibility of Lisp. Yet text data these days is a very rich construct. A typical string might be an entry in a Thai-Japanese dictionary. To accommodate general text data for the next hundred years, you must use Unicode (axiomatic, whether you realize it or not), which implies that the code itself (being data) must be in Unicode, which has implications for the semantics of code and how you walk through a string-as-list "character by character". Are you planning to have macros? Of course you are, which means that macros will be designed based on the assumption that what they parse is Unicode. What implications does that assumption have for the design of macro syntax? I don't know, but if you start by designing macros on the basis of ASCII assumptions, your macros will become a mess when you eventually try to retrofit Unicode. Most languages don't have to deal with this, because code and data are assumed separate.
I don't know how Lisp-style strings-as-lists should be designed when the strings are Unicode, and how, therefore, macros should be designed, but it seems pretty darned fundamental, not something to tack on later. And this is just the first example that comes to mind. Fundamental decisions have implications for ease of learning the language, ease of evolving code, for performance, for ability to run in parallel, for difficulty of implementation, for portability, for security, and for so many issues that I'm not even aware of, all of which have implications for one another.
No group of half-dozen friends, no matter how smart, knows enough to get these axioms right. Too many lessons have been learned by the rest of the world to ignore what they've found and hope to do well by reasoning from some incomplete set of first principles.
Of course, if you're just trying to solve a fun math problem by eliminating the parts of the real world you don't feel like thinking about, then fine. Those of us who need real tools will look elsewhere. You can publish the solution to your math puzzle. You may just not have the time or inclination to do more, and who could blame you? You're obviously very busy. But if it is intended as a tool for real programming, then carefully designing only the parts you care about will produce yet another mess of poorly integrated retrofits and kludges as the lessons long learned by the rest of the world (post-McCarthy) are belatedly rediscovered. Without project management that includes leveraging the expertise of a large community, Arc probably won't be usable as anything more than a source of ideas for the real 100-year language.
No, it's not "just an implementation detail". I don't want to get into the details here, but your assumption that having your strings in one encoding composed conceptually of code points in a different encoding is not necessarily the way to go. I was on a JCP expert committee that rejected that option for Java, but that doesn't mean it couldn't end up best for Arc. It's just not as easy a decision as you imply. There are alternative approaches with different pros and cons, and since these abstractions all leak, you need to make a cross-implementation decision so that you don't end up with different coding practices on different platforms. Plus all the other issues that Unicode presents that make parsing a challenge that might have implications for a language that is famous for parsing and rewriting its own source at runtime.... These could all be worked out through a vigorous discussion process among a diverse group large enough to make sure that the implications of each approach are understood, but Graham doesn't work that way.
Comments
"Axioms" has a nice, mathy ring of solidity to it, but I'm pretty sure that, along with the axioms you are analyzing there are others you are barely thinking about but which also form the foundation of Arc. For example, the notion of code and data being the same in Lisp: strings of text. Is that an axiom? That's certainly one of the keys to the unusual power and flexibility of Lisp. Yet text data these days is a very rich construct. A typical string might be an entry in a Thai-Japanese dictionary. To accommodate general text data for the next hundred years, you must use Unicode (axiomatic, whether you realize it or not), which implies that the code itself (being data) must be in Unicode, which has implications for the semantics of code and how you walk through a string-as-list "character by character". Are you planning to have macros? Of course you are, which means that macros will be designed based on the assumption that what they parse is Unicode. What implications does that assumption have for the design of macro syntax? I don't know, but if you start by designing macros on the basis of ASCII assumptions, your macros will become a mess when you eventually try to retrofit Unicode. Most languages don't have to deal with this, because code and data are assumed separate.
I don't know how Lisp-style strings-as-lists should be designed when the strings are Unicode, and how, therefore, macros should be designed, but it seems pretty darned fundamental, not something to tack on later. And this is just the first example that comes to mind. Fundamental decisions have implications for ease of learning the language, ease of evolving code, for performance, for ability to run in parallel, for difficulty of implementation, for portability, for security, and for so many issues that I'm not even aware of, all of which have implications for one another.
No group of half-dozen friends, no matter how smart, knows enough to get these axioms right. Too many lessons have been learned by the rest of the world to ignore what they've found and hope to do well by reasoning from some incomplete set of first principles.
Of course, if you're just trying to solve a fun math problem by eliminating the parts of the real world you don't feel like thinking about, then fine. Those of us who need real tools will look elsewhere. You can publish the solution to your math puzzle. You may just not have the time or inclination to do more, and who could blame you? You're obviously very busy. But if it is intended as a tool for real programming, then carefully designing only the parts you care about will produce yet another mess of poorly integrated retrofits and kludges as the lessons long learned by the rest of the world (post-McCarthy) are belatedly rediscovered. Without project management that includes leveraging the expertise of a large community, Arc probably won't be usable as anything more than a source of ideas for the real 100-year language.
What you talk about regarding unicode for example is just an implementation detail. Unicode strings fundamentally are a list of unicode code points.
UTF-8 is just one of the possible encodings of such list. It can be decoded and converted to UTF-32 before it goes to the reader/lexer.
No, it's not "just an implementation detail". I don't want to get into the details here, but your assumption that having your strings in one encoding composed conceptually of code points in a different encoding is not necessarily the way to go. I was on a JCP expert committee that rejected that option for Java, but that doesn't mean it couldn't end up best for Arc. It's just not as easy a decision as you imply. There are alternative approaches with different pros and cons, and since these abstractions all leak, you need to make a cross-implementation decision so that you don't end up with different coding practices on different platforms. Plus all the other issues that Unicode presents that make parsing a challenge that might have implications for a language that is famous for parsing and rewriting its own source at runtime.... These could all be worked out through a vigorous discussion process among a diverse group large enough to make sure that the implications of each approach are understood, but Graham doesn't work that way.