3 ms·

This dovetails to some degree with thoughts that I've been having about language and expression design. Associativity and operator precedence are ideas that ma

This dovetails to some degree with thoughts that I've been having about language and expression design. Associativity and operator precedence are ideas that made sense as a shorthand in written mathematics (and have deep roots in the structure of arithmetic) but don't actually add a lot of value in programming languages, except to put a huge mental burden on developers to unpack the precedence. My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)". In my experience, though, especially in programming (though not always in financial programming), there are almost always semantics associated with those intermediate values which makes one of the two groupings preferable. Taking numeric constants and adding internal separators makes a lot of sense as well (both before and after the decimal point). Ideally this would be enforced at some arbitrary cultural level, (e.g. using the US-standard groupings of three with comma), and would be required -- "2000" is invalid and "20,00" is invalid (so python3's approach of allowing arbitrary _'s in numbers is not really great, because it doesn't protect against typos). The right-of-the-decimal-point separators are not really common, but it would be nice to take advantage of this to make a sensible arbitrary enforced designation, like using "," to the left and "_" to the right, once again mandatory and required to support groupings of three. Would probably also be desirable to have a convention for hexadecimal numbers and other supported bases -- in particular binary is not supported by many languages, but is very natural for most programming languages, if we had a way of using delimiters -- 0b0100_0000 is more readable and meaningful than 0x40, but 0b0010_0100_0011_0010_0000_0010_0010 is not so good (quick, how many bytes did I just type?).

simongray 7y ago
> My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)". Or how about... (+ a b (/ c 2))
- c3534l 7y ago
  Still a bunch of pointless parens. Obviously a b + c 2 / or even / 2 c + b a is the more efficient, unambiguous notation.
  - jonsen 7y ago
    a b + c 2 / + or + a + b / c 2
- andrewla 7y ago
  I think S-expressions are annoying in that they tend to infect a language. If you're not careful, every function invocation becomes an s-expr, and you're left with the idea that + is no different from any other function, so we could write things like "plus(a, b, divide(c,2))" if we wanted to make a functional notation. And S-exprs don't save us from associativity, here you've made + associative, which is, fine, I guess, but what does (- a b c) mean, or (/ a b c)? This sort of asymmetry is a burden that isn't worth dealing with in my mind. On thing that I think imperative languages bring to the table is naming intermediate values through assignment, so we can do things like base_index = root_index + offset midpoint = length / 2 final_index = base_index + midpoint It's rarely useful to be so verbose, but it's nice to have the ability.
  - BalinKing 7y ago
    (Assuming I'm understanding correctly,) I'm honestly curious why `+` _should_ be different from any other function. (Also, AFAIK the ability of naming intermediate values is totally separate from imperativeness; see Haskell's `let` form, for example.)

simongray 7y ago

> My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)". Or how about... (+ a b (/ c 2))

c3534l 7y ago
Still a bunch of pointless parens. Obviously a b + c 2 / or even / 2 c + b a is the more efficient, unambiguous notation.
- jonsen 7y ago
  a b + c 2 / + or + a + b / c 2
andrewla 7y ago
I think S-expressions are annoying in that they tend to infect a language. If you're not careful, every function invocation becomes an s-expr, and you're left with the idea that + is no different from any other function, so we could write things like "plus(a, b, divide(c,2))" if we wanted to make a functional notation. And S-exprs don't save us from associativity, here you've made + associative, which is, fine, I guess, but what does (- a b c) mean, or (/ a b c)? This sort of asymmetry is a burden that isn't worth dealing with in my mind. On thing that I think imperative languages bring to the table is naming intermediate values through assignment, so we can do things like base_index = root_index + offset midpoint = length / 2 final_index = base_index + midpoint It's rarely useful to be so verbose, but it's nice to have the ability.
- BalinKing 7y ago
  (Assuming I'm understanding correctly,) I'm honestly curious why `+` _should_ be different from any other function. (Also, AFAIK the ability of naming intermediate values is totally separate from imperativeness; see Haskell's `let` form, for example.)