Here is a piece of my bnf grammer.
//this works
<ter-stmnt> ::= <rval> '?' <rval> ':' <rval>
//this gets an error
<ter-stmnt> ::= <bool-val> '?' <rval> ':' <rval>
<bool-val> ::= <rval>
This seems insane, shouldnt the second be EXACTLY the same as the first? i prefer the second bc when reading i see that i expect a bool value as oppose to the generic rval which can mean anything.
I am using Gold Parser 3.4.4
The error that you're getting is:
Reduce-Reduce Conflict
'?' can follow more than one completed rule. A Reduce-Reduce error is a caused when a grammar allows two or more rules to be reduced at the same time, for the same token. The grammar is ambigious. Please see the documentation for more information.
It's saying that after it's evaluated some tokens, it's unable to decide whether it's just read a <bool-val> or whether it read an <rval>.
To make more sense your grammar ought to say what a <bool-val> is, specifically, and then say that an <rval> is a <bool-val> or other things.
Here's another example of a reduce/reduce error, and here's the GOLD documentation. Gold will try to hide (i.e. emit a warning instead of an error) about a shift/reduce, but it treats reduce/reduce as an error.
I don't entirely understand this; I'm new to parsing. Maybe you're right about this being unexpected behaviour? However the GOLD mailing list seems to be down at the moment, perhaps because it's moderated and Devin has been offline for months.
What error do you get? Can you include your whole grammar file? I don't get any error if I declare rules like ...
<ter-stmnt> ::= <bool-val> '?' <rval> ':' <rval>
<bool-val> ::= <rval>
<rval> ::= '!'
Related
I understand when and how to use => in Ada, specifically when using the keyword 'others', but I am not sure of its proper name nor how and why it was created. The history and development of Ada is very interesting to me and I would appreciate anyone's insight on this.
=> is called arrow. It is used with any form of parameter, not only with the parameter 'others'.
Section 6.4 of the Ada Reference Manual states:
parameter_association ::= [formal_parameter_selector_name =>]
explicit_actual_parameter
explicit_actual_parameter ::= expression | variable_name
A parameter_association is named or positional according to whether or
not the formal_parameter_selector_name is specified. Any positional
associations shall precede any named associations. Named associations
are not allowed if the prefix in a subprogram call is an
attribute_reference.
Similarly, array aggregates are described in section 4.3.3
array_aggregate ::= positional_array_aggregate |
named_array_aggregate
positional_array_aggregate ::=
(expression, expression {, expression}) | (expression {, expression}, others => expression) | (expression {, expression},
others => <>)
named_array_aggregate ::=
(array_component_association {, array_component_association})
array_component_association ::=
discrete_choice_list => expression | discrete_choice_list => <>
The arrow is used to associate an array index with a specific value or to associate a formal parameter name of a subprogram with the actual parameter.
Stack Overflow isn’t really the place for this kind of question, which is why it's received at least one close vote.
That said, "arrow" has been present in the language since its first version; see ARM83 2.2. See also the Ada 83 Rationale; section 3.5 seems to be the first place where it’s actually used, though not by name.
As a complement to Jim's answer, on the usage/intuitiveness side: the arrow X => A means in various places of the Ada syntax: value A goes to place X. It is very practical, for instance, to fill an array with an arbitrary cell order. See slide 8 of this presentation for an application with large arrays. Needless to say that the absence of the arrow notation would lead to a heap of bugs in such a case. Sometimes it is just useful for making the associations more readable. You can see it here in action for designing a game level.
I'm trying to update large complexe json files and exit with detailled error message when detecting incoherent data (with jq 1.6).
I started to use functions and try/catch to produce a kind of java stacktrace containing input data from each level => easy, thank you JQ
But when I started to update array elements (using |=), I didn't find the solution
Here is a very simple example :
echo '{"array": [{"foo":"bar"}]}' | jq -c '.array[] |= try . catch (.)'
output : {"array":[{"__jq":0}]}
Do I made a mistake ? Is it a normal behaviour ?
Thanks for your help
The try-catch isn't really an expression, it yields no meaningful value, it merely executes some expression:
try-catch
Errors can be caught by using try EXP catch EXP. The first expression is executed, and if it fails then the second is executed with the error message. The output of the handler, if any, is output as if it had been the output of the expression to try.
emphasis mine.
So it would be wrong to use the value, you should perform the assignment within the try expression.
$ echo '{"array": [{"foo":"bar"}]}' | jq -c 'try (.array[] |= .) catch (.)'
You have stumbled upon a bug in jq 1.6. Using jq 1.5, one obtains the correct output:
{"array":[{"foo":"bar"}]}
However, the expression .array[] |= try . catch (.) is not one would ever use in practice, because if .array is a JSON array or JSON object, it just says: do nothing.
To understand try ... catch ..., it might help to consider this example:
$ jq -n 'try error("abc") catch ("The error message was " + .)'
"The error message was abc"
In the man page for the GNU version of find, at the end of the
EXPRESSIONS: ACTIONS: -printf section, is the following perplexing line:
A '%' at the end of the format
argument causes undefined behaviour since there is no following
character. In some locales, it may hide your door keys, while in
others it may remove the final page from the novel you are
reading.
I like the imagery, but what the does this actually mean? The find utility does not actually allow such a printf argument to be processed:
> find -printf "%"
find: error: % at end of format string
Inspection of the source code for reasonably recent versions of GNU find shows that it checks for this condition (a trailing %) and aborts with the error you indicate, so the excerpt from the man page appears to be nonsense.
I honestly can't imagine it ever behaved otherwise, so I doubt this excerpt was ever true.
My best guess is that the person writing the documentation somehow got it into their head that find's printf formats were somehow passed directly to the C library's printf function (which is ridiculous) and that the C library code might take some bizarre, locale-dependent action (which also seems ridiculous).
Suppose I have a rule:
myCoolRule:
Word
| 'myCoolToken' Word otherRule
I supply as input myCoolToken something else now it attempts to parse it greedily matches myCoolToken as a word and then hits the something and says uhhh I expected EOF, if I arrange the rules so it attempts to match myCoolToken first all is good and parses perfectly, for that input.
I am wondering if it is possible for it to keep trying all the rules in that statement to see if any works. So it matches Word fails, comes back and then tries the next rule.
Here is the actual grammar rules causing problems:
columnName = Word;
typeName = Word;
//accepts CAST and cast
cast = { MATCHES_IGNORE_CASE(LS(1), #"CAST") }? Word ;
checkConstraint = 'CHECK' '('! expr ')'!;
expr = requiredExp optionalExp*;
requiredExp = (columnName
| cast '(' expr as typeName ')'
... more but not important
optionalExp ...not important
The input CHECK( CAST( abcd as defy) ) causes it to fail, even though it is valid
Is there a construct or otherwise to make it verify all rules before giving up.
Creator of PEGKit here.
If I understand your question, No, this is not possible. But this is a feature of PEGKit, not a bug.
Your question is related to "determinacy" vs "nondeterminacy". PEGKit is a "deterministic" toolkit (which is widely considered a desirable feature for parsing programming languages).
It seems you are looking for a more "nondeterministic" behavior in this case, but I don't think you should be :).
PEGKit allows you to specify the priority of alternate options via the order in which the alternate options are listed. So:
foo = highPriority
| lowerPriority
| lowestPriority
;
If the highPriority option matches the current input, the lowerPriority and lowestPriority options will not get a chance to try to match, even if they are somehow a "better" match (i.e. they match more tokens than highPriority).
Again, this is related to "determinacy" (highPriority is guaranteed to be given primacy) and is widely considered a desirable feature when parsing programming languages.
So if you want your cast() expressions to have a higher priority than columnName, simply list the cast() expression as an option before the columnName option.
requiredExp = (cast '(' expr as typeName ')'
| columnName
... more but not important
OK, so that takes care of the syntactic details. However, if you have higher-level semantic constraints which can affect parsetime decisions about which alternative should have the highest priority, you should use a Semantic Predicate, like:
foo = { shouldChooseOpt1() }? opt1
| { shouldChooseOpt2() }? opt2
| defaultOpt
;
More details on Semantic Predicates here.
Basically, I've written a parser for a language with just basic arithmetic operators ( +, -, * / ) etc, but for the minus and plus cases, the Abstract Syntax Tree which is generated has parsed them as right associative when they need to be left associative. Having googled for a solution, I found a tutorial that suggests rewriting the rule from:
Expression ::= Expression <operator> Term | Term`
to
Expression ::= Term <operator> Expression*
However, in my head this seems to generate the tree the wrong way round. Any pointers on a way to resolve this issue?
First, I think you meant
Expression ::= Term (<operator> Expression)*
Back to your question: You do not need to "resolve the issue", because ANTLR has no problem dealing with tail recursion. I'm nearly certain that it replaces tail recursion with a loop in the code that it generates. This tutorial (search for the chapter called "Expressions" on the page) explains how to arrive at the e1 = e2 (op e2)* structure. In general, though, you define expressions in terms of higher-priority expressions, so the actual recursive call happens only when you process parentheses and function parameters:
expression : relationalExpression (('and'|'or') relationalExpression)*;
relationalExpression : addingExpression ((EQUALS|NOT_EQUALS|GT|GTE|LT|LTE) addingExpression)*;
addingExpression : multiplyingExpression ((PLUS|MINUS) multiplyingExpression)*;
multiplyingExpression : signExpression ((TIMES|DIV|'mod') signExpression)*;
signExpression : (PLUS|MINUS)* primeExpression;
primeExpression : literal | variable | LPAREN expression /* recursion!!! */ RPAREN;