Sometimes in Scheme, I have functions that take arguments like this
add 3 4
What do you call this kind of "list" where it's elements are like a1 a2 a3 ? I don't think you can call it a list because lists are contained in parenthesis and elements are comma-seperated.
The (add 3 4) statement is "function application" from the lambda calculus. The 3 4 from the expression are bindings for the parameters; alternatively, it is the parameter list for the function.
s-expression?
Lisp uses prefix or Polish notation syntax.
Polish notation, also known as prefix
notation, is a form of notation for
logic, arithmetic, and algebra. Its
distinguishing feature is that it
places operators to the left of their
operands. If the arity of the
operators is fixed, the result is a
syntax lacking parentheses or other
brackets, that can still be parsed
without ambiguity.
add is the operator and the right part are the operands.
The arity of the operators isn't fixed so Lisp uses parens in it's syntax to group the expressions.
Related
The question comes when I tried to make a macro like this:
#define OP1(a,b,op) (a) op (b)
then I was wondering why not also put op into parentheses, as it is also a macro parameter.
I then find I cannot even have this:
1 (+) 1;
otherwise there will be error:
error: expected primary-expression before ')' token
Can anyone tell me where is the rule saying operator cannot be in parentheses? I really cannot find it. Thank you.
§ 7.6.6 (expr.add) defines "additive expressions" as:
additive-expression:
multiplicative-expression
additive-expression + multiplicative-expression
additive-expression - multiplicative-expression
No parens around the operator allowed.
There actually isn't any rule that says an operator should not be in parenthesis. But there is a rule that states that, "for a binary operator like +, the value on either sides of the operator must be valid operands like 5, 5.2".
So the expression (+) to the compiler means you are adding two parentheses (left paren, plus, right paren) together which is not supported by the language.
Putting macro parameters in parenthesis is good practice of course, but there is actually no need for putting the operator in this case inside parenthesis as there is no way of passing a complicated operator expression so you can rest assured that your macro will always work.
In programming, as in mathematics, the parentheses are used to override the operators precedence.
Without parentheses, 2 + 3 * 4 is evaluated as 2 + (3 * 4) because the multiplication (*) has a higher precedence than the addition (+). One can use parentheses to force the addition of 2 and 3 happen before the multiplication (of the result) by 4 by placing them around the addition operator and its operands as (2 + 3) * 4.
Both 3 * 4 and 2 + 3 in the expressions above are valid expressions.
+ in the expression 1 (+) 2 is not a valid expression. More, assuming the parentheses contain a valid sub-expression, the entire expression is invalid because it is just a list of values without operators to connect them into an expression.
Even more, this is also not the way you learned in school to write mathematical expressions.
Back to your #define, to avoid hidden errors and headache (due to the operators precedence) you should always enclose the expanded value of such a macro into parentheses like this:
#define OP1(a,b,op) ((a) op (b))
I have an expression like below;
abs(sum(Max(abs(ListInput)),Min(V1,V2)))
I want to take out operators which take single argument which is a symbol for a list of arguments , stored somewhere else.
For example in above case;
Max(abs(ListInput))
is what I need.
I am able to do it iteratively by tokenizing and converting the expression in to reverse polish notation.
But things break when operator is ternary.
IF(10 > Max(Abs(ListInput)),5,MAX(ListInput)) // (IF<EXPRESSION>,TRUEVALUE,FALSEVALUE) ; True value and Valse value can also be an expression.
I am trying to figure out to a recursive way to do this , but unable to think through all conditions.
I want to take out operators which take single argument which is a
symbol for a list of arguments … regex
/(abs|sum|max|min)\([^(),]*(\([^(),]*\)[^(),]*)*\)/gi
Online regex tester
This question already has answers here:
How does the compiler know that the comma in a function call is not a comma operator?
(6 answers)
Closed 8 years ago.
In C++, the comma token (i.e., ,) is either interpreted as a comma operator or as a comma separator.
However, while searching in the web I realized that it's not quite clear in which cases the , token is interpreted as the binary comma operator and where is interpreted as a separator between statements.
Moreover, considering multiple statements/expressions in one line separated by , (e.g., a = 1, b = 2, c = 3;), there's a turbidness on the order in which they are evaluated.
Questions:
In which cases a comma , token is interpreted as an operator and in which as a separator?
When we have one line multiple statements/expressions separated by comma what's the order of evaluation for either the case of the comma operator and the case of the comma separator?
When a separator is appropriate -- in arguments to a function call or macro, or separating values in an initializer list (thanks for the reminder, #haccks) -- comma will be taken as a separator. In other expressions, it is taken as an operator. For example,
my_function(a,b,c,d);
is a call passing four arguments to a function, whereas
result=(a,b,c,d);
will be understood as the comma operator. It is possible, through ugly, to intermix the two by writing something like
my_function(a,(b,c),d);
The comma operator is normally evaluated left-to-right.
The original use of this operation in C was to allow a macro to perform several operations before returning a value. Since a macro instantiation looks like a function call, users generally expect it to be usable anywhere a function call could be; having the macro expand to multiple statements would defeat that. Hence, C introduced the , operator to permit chaining several expressions together into a single expression while discarding the results of all but the last.
As #haccks pointed out, the exact rules for how the compiler determines which meaning of , was intended come out of the language grammar, and have previously been discussed at How does the compiler know that the comma in a function call is not a comma operator?
You cannot use comma to separate statements. The , in a = 1, b = 2; is the comma operator, whose arguments are two assignment expressions. The order of evaluation of the arguments of the comma operator is left-to-right, so it's clear what the evaluation order is in that case.
In the context of the arguments to a function-call, those arguments cannot be comma-expressions, so the top-level commas must be syntactic (i.e. separating arguments). In that case, the evaluation order is not specified. (Of course, the arguments might be parenthesized expressions, and the parenthesized expression might be a comma expression.)
This is expressed clearly in the grammar in the C++ standard. The relevant productions are expression, which can be:
assignment-expression
or
expression , assignment-expression
and expression-list, which is the same as an initializer-list, which is a ,-separated list of initializer-clause, where an initializer-clause is either:
assignment-expression
or
braced-init-list
The , in the second expression production is the comma-operator.
I want to evaluate one expression in C++. To evaluate it, I want the expression to be converted to prefix format.
Here is an example
wstring expression = "Feature1 And Feature2";
Here are possible ways.
expression = "Feature1 And (Feature2 Or Feature3)";
expression = "Not Feature1 Or Feature3";
Here And, Or, Not are reserved words and parentheses ("(", )) are used for scope
Not has higher precedence
And is set next precedence to Not
Or is set to next precedence to And
WHITE SPACE used for delimiter. Expression has no other elements like TAB, NEWLINE
I don't need arithmetic expressions. I can do the evaluation but can somebody help me to convert the strings to prefix notation?
You will need to construct the grammar up front. So why do all the parsing by hand.
Instead use a parser builder library like Boost-Spirit. Or lex/yacc or flex/bison.
Then use the AST generated by the parser builder to output the data in any way you see fit. Such as infix to prefix or postfix, ...etc.
I guess your intention is to evaluate condition. hence you dont need a full fledged parser.
First of all you dont need to work with strings here.
1. Convert "Feature 1" to say an Id (An integer which represents a feature)
So, the statement "Feature1 And (Feature2 Or Feature3)"; to say (1 & (2 | 3)
From here on...you can use the standard Infix to prefix conversion and evaluate th prefix notation.
Here is the algorithm to convert infix to prefix
http://www.c4swimmers.esmartguy.com/in2pre.htm
http://www.programmersheaven.com/2/Art_Expressions_p1
Use a parser generator like the Lex/Yacc pair.
after this question, I don't know what to think.
In OCaml, if you do something like -1.0**2.0 (because of the typing you need to have float), you obtain 1.00. According to the standard order of operations, the result should be -1 (as in python).
I wasn't able to find the reason or a clear definition of the operator precedence in OCaml...
Is this because of the type system ? or the fact that there's a binding underneath with pow ?
As the very page you quote says, "The order in which the unary operator − (usually read "minus") acts is often problematical." -- it quotes Excel and bc as having the same priority for it as O'CAML, but also says "In written or printed mathematics" it works as in Python. So, essentially, there's no universal consensus on this specific issue.
Operator precedence is syntax-directed in OCaml, which means that the first character of the function identifier (and whether it's unary or binary) determines the operator precedence according to a fixed sequence. Contrast this with languages like Haskell, where the operator precedence can be specified at function definition regardless of which characters are used to form the function identifier.