"In most cases, though, it's better to work with people's illogical expectations.... Perhaps that's why Lisp never caught on."
I appreciate the insight here. I think that if the goal is to create a general-purpose programming language for consumption by the average population, it might be better to meet the expectations of the average person. I'm not saying that it needs to be C-like necessarily, but I think that you're right that things like order of operations and other expectations should probably be properly preserved, at least for mathematical operations.
I also realized that my approach was still wrong. If the goal is to be able to build any programming language, the left-to-right approach would already be limited to building a language which evaluates from left-to-right. So it seems that I still have work to do in order to figure out how best to design a language which is able to look like whatever the user desires it to.
One possibility is to sacrifice ease of macro-writing for making other areas of the language more consistent (but not Lisp-like). That is, I would like to keep the expressive power of macros high (even if it involves modifying the read table in some way) while keeping the language intuitive for a beginner. This would likely make it a bit more difficult to write macros, but by the time you are using macros a lot, you are probably a bit more advanced, anyways.
I'm thinking that there has to be some kind of grammar theory that I can leverage here, where the programmer could actually modify the language's parser in the program while maintaining consistency and lack of ambiguity, or being alerted to the potential ambiguity in case they fail to.
In any case, I am quite convinced that Lisp is probably one of the most ideal languages. This means that my hypothetical language may be an example of the phenomenon pg describes, where the best languages are those which are designed for use by the designer, and languages like Java and Cobol are the result of designing for others. I would like to hope that's not the case here, since I'm approaching this with a use-case in mind: to design a language which can be used to design any other language.
I appreciate the insight here. I think that if the goal is to create a general-purpose programming language for consumption by the average population, it might be better to meet the expectations of the average person. I'm not saying that it needs to be C-like necessarily, but I think that you're right that things like order of operations and other expectations should probably be properly preserved, at least for mathematical operations.
I also realized that my approach was still wrong. If the goal is to be able to build any programming language, the left-to-right approach would already be limited to building a language which evaluates from left-to-right. So it seems that I still have work to do in order to figure out how best to design a language which is able to look like whatever the user desires it to.
One possibility is to sacrifice ease of macro-writing for making other areas of the language more consistent (but not Lisp-like). That is, I would like to keep the expressive power of macros high (even if it involves modifying the read table in some way) while keeping the language intuitive for a beginner. This would likely make it a bit more difficult to write macros, but by the time you are using macros a lot, you are probably a bit more advanced, anyways.
I'm thinking that there has to be some kind of grammar theory that I can leverage here, where the programmer could actually modify the language's parser in the program while maintaining consistency and lack of ambiguity, or being alerted to the potential ambiguity in case they fail to.
In any case, I am quite convinced that Lisp is probably one of the most ideal languages. This means that my hypothetical language may be an example of the phenomenon pg describes, where the best languages are those which are designed for use by the designer, and languages like Java and Cobol are the result of designing for others. I would like to hope that's not the case here, since I'm approaching this with a use-case in mind: to design a language which can be used to design any other language.