4 ms·
> 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 pro
by 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 agoStill a bunch of pointless parens. Obviously a b + c 2 / or even / 2 c + b a is the more efficient, unambiguous notation.
- jonsen 7y agoa b + c 2 / + or + a + b / c 2
- andrewla 7y agoI 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.)