4 ms·

Any Lisp, but it turns out to reveal a bunch of Lisp warts. The most obvious one being that no Lisp out there ships with a built-in macro to do this. The subtle

Any Lisp, but it turns out to reveal a bunch of Lisp warts. The most obvious one being that no Lisp out there ships with a built-in macro to do this. The subtle truth, though, is that most people who use Lisp start out wanting this and then either give up before they become proficient enough to implement it, or else get acclimated to prefix math and once they are proficient, they don't care anymore. If you were to set out to do this, the first thing you'd have to accept is that the macro is going to look a little weird. For instance: (infixmath 2 + 3 * 4 * (2 + 1)) You're going to want to put spaces between all the terms, every time, because you'd rather have separate atoms for numbers and functions. The next problem you're going to run into is that Lisp doesn't ship with any context-free grammar support akin to Parsec or Yacc. This is the corollary to the point above, that once Lispers become proficient enough to do this they don't want to anymore. Once you're fully enamored with prefix notation, you never find yourself wishing for the kinds of grammar that necessitate this kind of work. (This has a lot to do with why most Lispers hate loop and format too). In other words, you'll be writing your own recursive descent parser from scratch. Once you've written your recursive descent parser to handle infix math, you'll face the next challenge: what to do with the parse tree. The simplest thing to do is just evaluate it. If you were really clever you might be building a Lisp prefix expression as you went and you can just let Lisp evaluate that directly with eval. A part of you will wonder if you should instead generate a compiled function, but then you have to capture the variables properly and it will be a lot more work, but it could become more efficient, since the Lisp compiler would have access to that information and could do better things with it... Anyway, my point is that this is sort of a will-o-the-wisp or mermaid example, because it's intended to capture the imaginations of non-Lispers, but actual Lispers have never actually gotten serious enough about it to make a robust implementation and ship it with the system, because the mindset that values infix math is incompatible with the mindset that produces good Lisp programmers.

betterunix 14y ago
The macro will not necessarily look weird, nor will you necessarily need to put spaces between the terms; in Common Lisp you have reader macros, and you can make this as simple as using [] to delimit regions of infix notations. As for why you do not see it done in practice, I would say it is mainly because it is not terribly useful in practice. Infix notation is just what most people are comfortable with, because they learned it in school; it has no real technical advantage, and the need for precedence rules is something of a disadvantage (though not a terribly major issue).
- fusiongyro 14y ago
  How many projects do you see promoting reader macros? The only package I ever used that came with one was CL-SQL, and it was really unpleasant to get everything working. Reader macros are another example of a feature that Lispers haul out when discussing the benefits of Lisp but never use in practice, because they're almost always more trouble than they're worth. The reason you perceive this as not terribly useful in practice is my overall point: once you're good enough with Lisp to develop this, you think in terms of s-exps and don't see the point. The primary technical advantage of infix notation is that the book you're getting the formula from used it, so it's easier to see if you transcribed it correctly. A secondary advantage is that it's what you use in your head and on paper. If the advantages of Lisp syntax outweigh the advantages of a lifetime of schooling and compatibility with the world at large, you are, at last, a Lisper. :)
  - lispm 14y ago
    Reader macros are there to extend s-expressions. Lisp developers who think in s-expressions use reader macros to implement new data structure syntax (sets, tables, JSON, ...), new code syntax (infix, SQL, Objective-C, ...), ...
  - betterunix 14y ago
    Actually I stopped seeing the point of infix notation long before I started programming in Lisp; infix notation stopped seeming like the cat's meow when I had to actually spend time thinking about how to parse it. I have yet to encounter a good argument for infix notation; all anyone seems to offer is, "Well it's what everyone knows and what we teach in schools!" I am not even sure that infix notation being taught in schools should be pointed to as a positive thing, given that "Please Excuse My Dear Aunt Sally" does nothing to improve anyone's understanding of math (when was the last time you saw PEMDAS written in a proof?). I'm sure there would be endless complaints from parents who were unable to help their children with their arithmetic homework if we suddenly switched to postfix notation in elementary school. I don't think mindlessly transcribing formulas from textbooks is a strong argument for infix notation, and it is definitely not a technical advantage. I am not entirely sure that infix is what people naturally use internally, either, as it is not unusual to hear people say things like, "subtract 3 from x" or "divide the sum of the numbers by the count" -- those look more like something you would see in Lisp than infix notation to me.
nnq 14y ago
I know that infix notations tends to push your intuition towards an imperative and sequential way of thinking somehow. Like, for an expression like: ( ...big thing 1... ) + ( ...big thing 2...) ...people tend to think like "compute 'big thing 1' and then, to this, add 'big thing 2'". ...but then again, "purer" languages like Haskell don't use prefix (yes, it's an alternative, but people just don't use it). And mathematical language, that is not imperative and sometimes not even sequential, uses infix. And List never made a fuss about being a "pure" functional language... it's more of a "multi paradingm" language. Still like Haskell's way of putting the operator on parentheses for prefix in infix by default, though H will definitely never be my favorite language...
- fusiongyro 14y ago
  I don't see how prefix notation would ameliorate this problem. You'll still wind up with: (+ ( ... big thing 1 ...) ( ... big thing 2 ...)) I don't think this syntax does a better job of conveying a lack of ordering between the two things. I'm inclined to argue that it's worse simply because Lisp is sequential and the math you did in school wasn't, so you have experience looking at the bigger picture with infix versus prefix. But both of us are bullshitting, because we haven't got any science to support one position or attack the other, only reasonable-seeming hypotheses. Haskell is my favorite language, but I find I get a lot more use out of converting words to operators than converting operators to "words." For example, I find this: x `elem` y a lot more intuitive than: elem x y because the infix version suggests the natural English reading, that the set is the second argument and the item is the first, where in the prefix case I have to think about it for a second.
  - nnq 14y ago
    ...true, it's bullshitting ...or it's an entirely subjective thing, depending on how you're used to think :) ...but it's that different feeling that "add 'big thing 1' with 'big thing 2'" vs. "compute 'big thing 1' and then add 'big thing 2' to it" ...and if you think of a programming language as an "interface" between your mind and the computer, and think of a programming language from a UI or UX design perspective, these subjective "how it feels" things really do matter. But indeed, Haskell wins on this one 100% by allowing you to just use whatever notation you like without having to write or use a reader macro or something like this. Anyway, back to real work now...

betterunix 14y ago

The macro will not necessarily look weird, nor will you necessarily need to put spaces between the terms; in Common Lisp you have reader macros, and you can make this as simple as using [] to delimit regions of infix notations. As for why you do not see it done in practice, I would say it is mainly because it is not terribly useful in practice. Infix notation is just what most people are comfortable with, because they learned it in school; it has no real technical advantage, and the need for precedence rules is something of a disadvantage (though not a terribly major issue).

fusiongyro 14y ago
How many projects do you see promoting reader macros? The only package I ever used that came with one was CL-SQL, and it was really unpleasant to get everything working. Reader macros are another example of a feature that Lispers haul out when discussing the benefits of Lisp but never use in practice, because they're almost always more trouble than they're worth. The reason you perceive this as not terribly useful in practice is my overall point: once you're good enough with Lisp to develop this, you think in terms of s-exps and don't see the point. The primary technical advantage of infix notation is that the book you're getting the formula from used it, so it's easier to see if you transcribed it correctly. A secondary advantage is that it's what you use in your head and on paper. If the advantages of Lisp syntax outweigh the advantages of a lifetime of schooling and compatibility with the world at large, you are, at last, a Lisper. :)
- lispm 14y ago
  Reader macros are there to extend s-expressions. Lisp developers who think in s-expressions use reader macros to implement new data structure syntax (sets, tables, JSON, ...), new code syntax (infix, SQL, Objective-C, ...), ...
- betterunix 14y ago
  Actually I stopped seeing the point of infix notation long before I started programming in Lisp; infix notation stopped seeming like the cat's meow when I had to actually spend time thinking about how to parse it. I have yet to encounter a good argument for infix notation; all anyone seems to offer is, "Well it's what everyone knows and what we teach in schools!" I am not even sure that infix notation being taught in schools should be pointed to as a positive thing, given that "Please Excuse My Dear Aunt Sally" does nothing to improve anyone's understanding of math (when was the last time you saw PEMDAS written in a proof?). I'm sure there would be endless complaints from parents who were unable to help their children with their arithmetic homework if we suddenly switched to postfix notation in elementary school. I don't think mindlessly transcribing formulas from textbooks is a strong argument for infix notation, and it is definitely not a technical advantage. I am not entirely sure that infix is what people naturally use internally, either, as it is not unusual to hear people say things like, "subtract 3 from x" or "divide the sum of the numbers by the count" -- those look more like something you would see in Lisp than infix notation to me.

nnq 14y ago

I know that infix notations tends to push your intuition towards an imperative and sequential way of thinking somehow. Like, for an expression like: ( ...big thing 1... ) + ( ...big thing 2...) ...people tend to think like "compute 'big thing 1' and then, to this, add 'big thing 2'". ...but then again, "purer" languages like Haskell don't use prefix (yes, it's an alternative, but people just don't use it). And mathematical language, that is not imperative and sometimes not even sequential, uses infix. And List never made a fuss about being a "pure" functional language... it's more of a "multi paradingm" language. Still like Haskell's way of putting the operator on parentheses for prefix in infix by default, though H will definitely never be my favorite language...

fusiongyro 14y ago
I don't see how prefix notation would ameliorate this problem. You'll still wind up with: (+ ( ... big thing 1 ...) ( ... big thing 2 ...)) I don't think this syntax does a better job of conveying a lack of ordering between the two things. I'm inclined to argue that it's worse simply because Lisp is sequential and the math you did in school wasn't, so you have experience looking at the bigger picture with infix versus prefix. But both of us are bullshitting, because we haven't got any science to support one position or attack the other, only reasonable-seeming hypotheses. Haskell is my favorite language, but I find I get a lot more use out of converting words to operators than converting operators to "words." For example, I find this: x `elem` y a lot more intuitive than: elem x y because the infix version suggests the natural English reading, that the set is the second argument and the item is the first, where in the prefix case I have to think about it for a second.
- nnq 14y ago
  ...true, it's bullshitting ...or it's an entirely subjective thing, depending on how you're used to think :) ...but it's that different feeling that "add 'big thing 1' with 'big thing 2'" vs. "compute 'big thing 1' and then add 'big thing 2' to it" ...and if you think of a programming language as an "interface" between your mind and the computer, and think of a programming language from a UI or UX design perspective, these subjective "how it feels" things really do matter. But indeed, Haskell wins on this one 100% by allowing you to just use whatever notation you like without having to write or use a reader macro or something like this. Anyway, back to real work now...