5 ms·

> Unlike in most other languages, operators always have the same precedence and expressions are evaluated in right-associative order. That is, unary operators a

by titzer 4y ago

> Unlike in most other languages, operators always have the same precedence and expressions are evaluated in right-associative order. That is, unary operators apply to everything to the right, and binary operators apply to the operand immediately to the left and to everything to the right. Thus, 34+5 is 27 (it groups as 3(4+5)) This seems like a blatant unforced error.

mananaysiempre 4y ago
This is entirely in line with the APL tradition. I suspect part of the motivation is that APL has a lot of binary operators, none of which have a conventional infix form in traditional mathematics or anywhere else. (Cf also the Smalltalk tradition, which associates all “binary messages” to the left, but that has the motivation of allowing user-defined names without fixity declarations.)
anonymous_sorry 4y ago
Ivy is described as a "plaything". Rethinking rules that everyone takes for granted and seeing where it leads seems like a fun way to play. My first CASIO scientific calculator at school didn't understand operator precedence. Since that was how basic calculators worked too, it seemed perfectly natural. I loved that calculator - there was a simplicity and purity to it. When I got a fancier one at uni that had been taught BIDMAS, it took me a long while to get used to, and I never really enjoyed using it. I don't think it was just because the squidgier keys were less satisfying to tap.
cardanome 4y ago
Now, let's imagine an APL-like language with precedence: APL has a huge number of operators and worse, you can and will define your own, as the classic distinction between operators and functions does not apply to APL. So a huge precedence table to memorize! Plus, with user defined operators you would either have to force them to be all the same precedence, which is kind of a bummer, or you allow them to define their own precedence. It should be obvious that this would be a huge mess. So actually no having precedence is the most sane way forward but you also gain something: Order of precedence errors are quite common both in mathematics and programming. Doing away with precedence rules gets rid of a whole class of errors. Awesome! (If you are going to respond that you never make any errors, well congrats on being smart, I am not. I try to avoid relying on lesser known precedence rules in my code as best as I can.) So what do we gain from precedence rules again? Shorter and less noisy? Ugh, have you seen APL? I think they are good. The notation of APL is explicitly designed to be human friendly. Lot's of thought was put into it. I recommend reading this Iverson paper: http://www.sigapl.org/Articles/Notation%20as%20a%20Tool%20of%20Thought_a1979-iverson.pdf http://www.sigapl.org/Articles/Notation%20as%20a%20Tool%20of...

by titzer 4y ago

mananaysiempre 4y ago

This is entirely in line with the APL tradition. I suspect part of the motivation is that APL has a lot of binary operators, none of which have a conventional infix form in traditional mathematics or anywhere else. (Cf also the Smalltalk tradition, which associates all “binary messages” to the left, but that has the motivation of allowing user-defined names without fixity declarations.)

anonymous_sorry 4y ago

Ivy is described as a "plaything". Rethinking rules that everyone takes for granted and seeing where it leads seems like a fun way to play. My first CASIO scientific calculator at school didn't understand operator precedence. Since that was how basic calculators worked too, it seemed perfectly natural. I loved that calculator - there was a simplicity and purity to it. When I got a fancier one at uni that had been taught BIDMAS, it took me a long while to get used to, and I never really enjoyed using it. I don't think it was just because the squidgier keys were less satisfying to tap.

cardanome 4y ago

Now, let's imagine an APL-like language with precedence: APL has a huge number of operators and worse, you can and will define your own, as the classic distinction between operators and functions does not apply to APL. So a huge precedence table to memorize! Plus, with user defined operators you would either have to force them to be all the same precedence, which is kind of a bummer, or you allow them to define their own precedence. It should be obvious that this would be a huge mess. So actually no having precedence is the most sane way forward but you also gain something: Order of precedence errors are quite common both in mathematics and programming. Doing away with precedence rules gets rid of a whole class of errors. Awesome! (If you are going to respond that you never make any errors, well congrats on being smart, I am not. I try to avoid relying on lesser known precedence rules in my code as best as I can.) So what do we gain from precedence rules again? Shorter and less noisy? Ugh, have you seen APL? I think they are good. The notation of APL is explicitly designed to be human friendly. Lot's of thought was put into it. I recommend reading this Iverson paper: http://www.sigapl.org/Articles/Notation%20as%20a%20Tool%20of%20Thought_a1979-iverson.pdf http://www.sigapl.org/Articles/Notation%20as%20a%20Tool%20of...