7 ms·

This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write "x + y + z" This is a non-problem if

This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write "x + y + z" This is a non-problem if you're using Lisp. (+ x y z) accepts an arbitary number of arguments and the operator precedence problem does not exist since there is no operator precedence.

hjk05 8y ago
Try writing out typical mathematical formula derivations using only s-expressions. I tried for a period and abandoned the persuit. It’s just not comparable to established mathematical notation.
- michaelmrose 8y ago
  Two solutions. Threading macros wherein instead of nested parens like (x (y (z))) one writes ((->> z) y x) In clojure there is an interesting package https://github.com/rplevy/swiss-arrows https://github.com/rplevy/swiss-arrows which allows one to perform successive operations with explicit placement of the result of prior evaluation by placing a <> in the form ((->> (z <>)) (y <> 7) (x <>)) In practice it seems like there is often less need to do so as many similar functions or the same variety have the same ordering and other options like as-> exist too. There is also the idea of processing math expressions infix as expected when desired. https://github.com/rm-hull/infix https://github.com/rm-hull/infix ($= 3 + 5 * 8) ; => 43
- ken 8y ago
  The Lisp community has literally tried exactly this, on and off, for the past half century -- and they always come back to s-expressions. Every new Lisp programmers says "I know, I'll make a macro to let me write infix math!", and then abandons it 2 months later. It's not like Lisp programmers aren't aware of how schoolchildren write (+ 2 2). I've written tons of code in both language families. In infix/prefix (i.e., Algol-family) languages, I frequently wish for a nice consistent prefix syntax. In prefix-only (i.e., Lisp-family) languages, I can't say I've ever wished for infix notation. I don't understand what the perceived issue is with infix notation, except for unfamiliarity -- and that passes soon enough.
platz 8y ago
So you trade simplicity in one problem (precedence) and gain complexity in another (variadic arguments and (lang-dependent) multiple variadic function implementations)
- bjoli 8y ago
  You don't have to make your functions variadic, it is just handy when working with numbers.
QuadrupleA 8y ago
Lisp is pretty ugly :) (eql (* x (+ y z)) (+ (* x y) (* x z))) I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax. Edit: typo fix, had x/z mixed up
- explainplease 8y ago
  You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Edit: If you think lisp is ugly, compare with regexps. For bonus points, explore writing regexps with lisp, e.g. with Emacs's `rx` macro. I think you won't find a more easily maintainable way to write them.
  - chongli 8y ago
    Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.
    - dorfsmay 8y ago
      Are you talking about macro or formatting? If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions. If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.
ghettoimp 8y ago
Yup. In addition to ignoring the usual Lisp convention for associative operators, I think the article muddies the waters here by using words like "add" and "mul" in all of the non-infix examples, making them unnecessarily verbose. After using prefix notation for years, it seems very natural for pattern recognition and formula manipulation. Never having to think about precedence and associativity is really nice.
mannykannot 8y ago
If this is so obviously preferable, why have mathematicians so obdurately not adopted this style? Mathematical notation is not an archaic practice that is followed out of a respect for tradition, or a doctrine that has been developed from first principles, it is something that has evolved (and continues to do so) because it has been useful.
- bobbylarrybobby 8y ago
  Well mathematics notation largely follows speech. People say “one plus two” — largely because speech doesn’t have closing parentheses, so we need to speak in a way that makes it clear when we’re done talking — so that’s how we write it. But for a computer, prefix notation is great because it’s unambiguous and clear even without knowledge of PEMDAS. Similar to how Americans write MM/DD/YYYY because that’s how we say dates, but we can still acknowledge that YYYY-MM-DD is the best format for computers.
  - improbable22 8y ago
    I wonder how much is the reverse: we now tend to say mathematical expressions as they are written, but before this was standardised, you would just explain the steps. Probably not "one plus two" -- I think + is essentially a variant of & which is a ligature for "et", and I guess most languages put "and" between the things being combined. But I'd be surprised if (x/y)^2 was said "x over y all squared" by many people before this notation. But the notation is clearly more designed for thinking on paper than for explaining down a phone line.
- newen 8y ago
  Mathematics uses infix notation literally everywhere. Just because you prefer some notation doesn't mean people who have used infix notation since they were 5 years old will like it. Also, I avoid lisp mostly because S-expressions are almost unreadable to me.
  - dragonwriter 8y ago
    > Mathematics uses infix notation literally everywhere. Mathematics uses prefix, infix, suffix, circumfix, and some more complex notations; basically any pattern any computer language uses probably is inspired from math even if math doesn't use the notation for the same operation or operator symbol.
Rexxar 8y ago
This is a non-problem in every language with variadic functions. "add(x, y, z)" looks good to me.
- dnautics 8y ago
  You have to be careful though. In Julia, there is "fma(a,b,c)" which is not necessarily the same as "muladd(a,b,c)". What are the guarantees on add(a,b,c) versus a+b+c? If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative)
  - alboy 8y ago
    > If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative) You might be thinking of associativity. Both addition and multiplication are commutative up to NaN.
mturmon 8y ago
Your comment is begging the question. The reason that Lisp “+” can accept a list of arbitrary length, rather than a pair, is that the underlying addition operator is associative.
- ehaliewicz2 8y ago
  Not true. Division isn't associative and you can do e.g. (/ 12 6 3)
  - mturmon 8y ago
    This is true - Lisp is making / left-associative. But this observation does not change my point: that the parent comment is saying "Lisp already has the ability to do + on lists", but the reason "+ on lists" makes sense is because Lisp is using the underlying associativity of mathematical +. And the latter associativity property, for abstract mathematical "+", is what the blog post is describing/exploring.
    - kazinator 8y ago
      The computing + is not associative for inexact types like floating-point. That's why it's important for the Lisp + to be consistently left-associative; the result could vary if that were left to the implementation to do however it wants. In addition/relation to floating-point, another way in which addition is not associative in computing is if there are type conversions. (+ 1 1 0.1) is not the same as (+ 1 (+ 1 0.1)). The former will do an integer addition to produce 2, and then that is coerced to 2.0 which is added to 0.1. The latter adds 1.0 to 0.1, and then adds that to 1.0: two floating-point additions. In languages that don't have bignums (which could include some Lisp dialects) whether overflows occur can depend on the order of operations, even when all operands are integers. The reason we can have a n-ary + is that three or more arguments can be decimated through a binary +. The concept of + is defined as a binary operation. Lisps have variadic functions that are blatantly non-associative, like, oh, list. (list 1 2 3) isn't (list 2 3 1).

hjk05 8y ago

Try writing out typical mathematical formula derivations using only s-expressions. I tried for a period and abandoned the persuit. It’s just not comparable to established mathematical notation.

michaelmrose 8y ago
Two solutions. Threading macros wherein instead of nested parens like (x (y (z))) one writes ((->> z) y x) In clojure there is an interesting package https://github.com/rplevy/swiss-arrows https://github.com/rplevy/swiss-arrows which allows one to perform successive operations with explicit placement of the result of prior evaluation by placing a <> in the form ((->> (z <>)) (y <> 7) (x <>)) In practice it seems like there is often less need to do so as many similar functions or the same variety have the same ordering and other options like as-> exist too. There is also the idea of processing math expressions infix as expected when desired. https://github.com/rm-hull/infix https://github.com/rm-hull/infix ($= 3 + 5 * 8) ; => 43
ken 8y ago
The Lisp community has literally tried exactly this, on and off, for the past half century -- and they always come back to s-expressions. Every new Lisp programmers says "I know, I'll make a macro to let me write infix math!", and then abandons it 2 months later. It's not like Lisp programmers aren't aware of how schoolchildren write (+ 2 2). I've written tons of code in both language families. In infix/prefix (i.e., Algol-family) languages, I frequently wish for a nice consistent prefix syntax. In prefix-only (i.e., Lisp-family) languages, I can't say I've ever wished for infix notation. I don't understand what the perceived issue is with infix notation, except for unfamiliarity -- and that passes soon enough.

platz 8y ago

So you trade simplicity in one problem (precedence) and gain complexity in another (variadic arguments and (lang-dependent) multiple variadic function implementations)

bjoli 8y ago
You don't have to make your functions variadic, it is just handy when working with numbers.

QuadrupleA 8y ago

Lisp is pretty ugly :) (eql (* x (+ y z)) (+ (* x y) (* x z))) I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax. Edit: typo fix, had x/z mixed up

explainplease 8y ago
You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Edit: If you think lisp is ugly, compare with regexps. For bonus points, explore writing regexps with lisp, e.g. with Emacs's `rx` macro. I think you won't find a more easily maintainable way to write them.
- chongli 8y ago
  Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.
  - dorfsmay 8y ago
    Are you talking about macro or formatting? If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions. If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.

ghettoimp 8y ago

Yup. In addition to ignoring the usual Lisp convention for associative operators, I think the article muddies the waters here by using words like "add" and "mul" in all of the non-infix examples, making them unnecessarily verbose. After using prefix notation for years, it seems very natural for pattern recognition and formula manipulation. Never having to think about precedence and associativity is really nice.

mannykannot 8y ago

If this is so obviously preferable, why have mathematicians so obdurately not adopted this style? Mathematical notation is not an archaic practice that is followed out of a respect for tradition, or a doctrine that has been developed from first principles, it is something that has evolved (and continues to do so) because it has been useful.

bobbylarrybobby 8y ago
Well mathematics notation largely follows speech. People say “one plus two” — largely because speech doesn’t have closing parentheses, so we need to speak in a way that makes it clear when we’re done talking — so that’s how we write it. But for a computer, prefix notation is great because it’s unambiguous and clear even without knowledge of PEMDAS. Similar to how Americans write MM/DD/YYYY because that’s how we say dates, but we can still acknowledge that YYYY-MM-DD is the best format for computers.
- improbable22 8y ago
  I wonder how much is the reverse: we now tend to say mathematical expressions as they are written, but before this was standardised, you would just explain the steps. Probably not "one plus two" -- I think + is essentially a variant of & which is a ligature for "et", and I guess most languages put "and" between the things being combined. But I'd be surprised if (x/y)^2 was said "x over y all squared" by many people before this notation. But the notation is clearly more designed for thinking on paper than for explaining down a phone line.
newen 8y ago
Mathematics uses infix notation literally everywhere. Just because you prefer some notation doesn't mean people who have used infix notation since they were 5 years old will like it. Also, I avoid lisp mostly because S-expressions are almost unreadable to me.
- dragonwriter 8y ago
  > Mathematics uses infix notation literally everywhere. Mathematics uses prefix, infix, suffix, circumfix, and some more complex notations; basically any pattern any computer language uses probably is inspired from math even if math doesn't use the notation for the same operation or operator symbol.

Rexxar 8y ago

This is a non-problem in every language with variadic functions. "add(x, y, z)" looks good to me.

dnautics 8y ago
You have to be careful though. In Julia, there is "fma(a,b,c)" which is not necessarily the same as "muladd(a,b,c)". What are the guarantees on add(a,b,c) versus a+b+c? If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative)
- alboy 8y ago
  > If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative) You might be thinking of associativity. Both addition and multiplication are commutative up to NaN.

mturmon 8y ago

Your comment is begging the question. The reason that Lisp “+” can accept a list of arbitrary length, rather than a pair, is that the underlying addition operator is associative.

ehaliewicz2 8y ago
Not true. Division isn't associative and you can do e.g. (/ 12 6 3)
- mturmon 8y ago
  This is true - Lisp is making / left-associative. But this observation does not change my point: that the parent comment is saying "Lisp already has the ability to do + on lists", but the reason "+ on lists" makes sense is because Lisp is using the underlying associativity of mathematical +. And the latter associativity property, for abstract mathematical "+", is what the blog post is describing/exploring.
  - kazinator 8y ago
    The computing + is not associative for inexact types like floating-point. That's why it's important for the Lisp + to be consistently left-associative; the result could vary if that were left to the implementation to do however it wants. In addition/relation to floating-point, another way in which addition is not associative in computing is if there are type conversions. (+ 1 1 0.1) is not the same as (+ 1 (+ 1 0.1)). The former will do an integer addition to produce 2, and then that is coerced to 2.0 which is added to 0.1. The latter adds 1.0 to 0.1, and then adds that to 1.0: two floating-point additions. In languages that don't have bignums (which could include some Lisp dialects) whether overflows occur can depend on the order of operations, even when all operands are integers. The reason we can have a n-ary + is that three or more arguments can be decimated through a binary +. The concept of + is defined as a binary operation. Lisps have variadic functions that are blatantly non-associative, like, oh, list. (list 1 2 3) isn't (list 2 3 1).