associativity

Associativity of fold-expressions

假如想象 提交于 2019-12-05 16:44:51
问题 N4191 proposed fold-expressions to C++. The definition there was that (args + ...) is a left-fold (i.e. (((a0 + a1) + a2) + ...) , and that (... + args) is a right-fold (i.e. (... + (a8 + (a9 + a10))) . However, the revised paper N4295 reversed the definitions of left and right unary folds. Question : what is the rationale? It seems more intuitive (at least when you are used to left-to-right alphabets) to evaluate (args + ...) from left-to-right. 回答1: From the comment by @cpplearner, here's

Relation between grammar and operator associativity

倖福魔咒の 提交于 2019-12-05 06:26:57
Some compiler books / articles / papers talk about design of a grammar and the relation of its operator's associativity. I'm a big fan of top-down, especially recursive descent, parsers and so far most (if not all) compilers I've written use the following expression grammar: Expr ::= Term { ( "+" | "-" ) Term } Term ::= Factor { ( "*" | "/" ) Factor } Factor ::= INTEGER | "(" Expr ")" which is an EBNF representation of this BNF: Expr ::= Term Expr' Expr' ::= ( "+" | "-" ) Term Expr' | ε Term ::= Factor Term' Term' ::= ( "*" | "/" ) Factor Term' | ε Factor = INTEGER | "(" Expr ")" According to

C++: input and output stream operators: associativity

陌路散爱 提交于 2019-12-04 12:43:11
Input/Output stream operators associativity in theory: LEFT TO RIGHT (for example, according to this: Sait Mary's University website Input/Output stream operators associativity on practice: #include <iostream> int func0() { std::cout << "func0 executed" << std::endl; return 0; } int func1() { std::cout << "func1 executed" << std::endl; return 1; } int func2() { std::cout << "func2 executed" << std::endl; return 2; } int main() { std::cout << func0() << func1() << func2() << std::endl; return 0; } Output (MSVCPP 2010, 2012): func2 executed func1 executed func0 executed 012 Press any key to

Why are logical operators in JavaScript left associative?

霸气de小男生 提交于 2019-12-04 08:54:27
问题 The logical AND and OR operators are the only lazy operators in JavaScript along with the ternary conditional operator. They are tested for short-circuit evaluation using the following rules: false && anything === false true || anything === true This is the same way it is implemented in Haskell: (&&) :: Bool -> Bool -> Bool False && _ = False True && x = x (||) :: Bool -> Bool -> Bool True || _ = True False || x = x However according to MDN logical operators in JavaScript are left associative

Associativity of fold-expressions

℡╲_俬逩灬. 提交于 2019-12-04 01:30:20
N4191 proposed fold-expressions to C++. The definition there was that (args + ...) is a left-fold (i.e. (((a0 + a1) + a2) + ...) , and that (... + args) is a right-fold (i.e. (... + (a8 + (a9 + a10))) . However, the revised paper N4295 reversed the definitions of left and right unary folds. Question : what is the rationale? It seems more intuitive (at least when you are used to left-to-right alphabets) to evaluate (args + ...) from left-to-right. From the comment by @cpplearner, here's some archeology from std-discussion On Wed, Feb 4, 2015 at 1:30 AM, @T.C. wrote : In N4295, which was

Is right-to-left operator associativity in R possible?

↘锁芯ラ 提交于 2019-12-03 16:16:33
问题 I'm new to R, and I just discovered I suffer from Bracket Phobia (see comment in the link). I like the way magrittr notation %>% works, because it avoids nested parenthesis in some situations, and makes code more readable. I came from Mathematica , where there is a very similar native // notation to do what %>% does. Here are some R and Mathematica comparisons: #R Notation c(1.5,-2.3,3.4) %>% round %>% abs %>% sum #Mathematica Notation {1.5,-2.3,3.4}//Round//Abs//Total So far so good, but, my

Why does the expression (true == true == true) produce a syntax error?

和自甴很熟 提交于 2019-12-03 05:22:02
问题 Ruby : true == true == true syntax error, unexpected tEQ vs. JavaScript : true == true == true // => true vs. C : 1 == 1 == 1 // => 1 回答1: Association direction, which controls the order of operators having their arguments evaluated, is not defined for the == method, same as for === , != , =~ and <=> methods as well (all of which have the same precedence and form a separate precedence group exclusively). Documentation Thus evaluation order in case of multiple operators from the list mentioned

Is right-to-left operator associativity in R possible?

筅森魡賤 提交于 2019-12-03 04:41:59
I'm new to R, and I just discovered I suffer from Bracket Phobia (see comment in the link). I like the way magrittr notation %>% works, because it avoids nested parenthesis in some situations, and makes code more readable. I came from Mathematica , where there is a very similar native // notation to do what %>% does. Here are some R and Mathematica comparisons: #R Notation c(1.5,-2.3,3.4) %>% round %>% abs %>% sum #Mathematica Notation {1.5,-2.3,3.4}//Round//Abs//Total So far so good, but, my question is: Is there some way to mimic Mathematica @ notation , with right-to-left associativity in R

Why is function composition in Haskell right associative?

♀尐吖头ヾ 提交于 2019-12-02 17:58:33
Mathematically the function composition operation is associative. Hence: f . (g . h) = (f . g) . h Thus the function composition operation may be defined to be either left associative or right associative. Since normal function application in Haskell (i.e. the juxtaposition of terms, not the $ operation) is left associative in my opinion function composition should also be left associative. After all most people in the world (including myself) are used to reading from left to right. Nevertheless function composition in Haskell is right associative: infixr 9 . I know that it doesn't really make

C99 associativity for operators - where is it specified?

喜夏-厌秋 提交于 2019-12-01 15:05:01
问题 In the C99 standard, the expressions allow for precedence and associativity. Precedence is documented quite well since the order in which the operators appear in the document are of reducing precedence, so function calls come before multiplicative operators which, in turn, come before additive operators. However, I can't find a definitive description of the associativity, whether it's left or right. This is important since 35/5*2 would be 14 for one variant (35/5)*2 and 3 for the other