Been a while since I've worked w/ CFG. Anyways, I have a particular grammar that goes through all the operations properly, but at the end (I excluded other standard mathematic operations).
S ::= S+T | S-T | T
T ::= nonterminal | ID | -S | (S)
per everything I have.. I know that -S should be -T. But additionally.. what does that do to the precedence. Is it ambiguous? Mathematically I can it obviously won't be correct.. but that shouldn't make a difference on the issue of ambiguity.
If it was a -T would that have equal precedence as the (S)?
really trying to comprehend how this occurs with it looping back to the Start state.
If you change -S to -T, the ambiguity is solved.
Before the change, here is an example for an ambiguous sentence: -a-b. Is it -(a-b), or (-a)-b?
With the change, however, there is no more ambiguity.
As for precedence, in your specific example, there doesn't have to be a rule between -T and (S), since it is always the inner one that has precedence, which is exactly the behavior you would expect.
Related
I sometimes use this:
$ perl -e "printf \"%d\", ((~18446744073709551592)+1)"
24
I can't seem to do it with Raku. The best I could get is:
$ raku -e "say +^18446744073709551592"
-18446744073709551593
So: how can I make Raku give me the same answer as Perl ?
Gotta go with (my variant¹ of) Liz's custom op (in her comment below).
sub prefix:<²^>(uint $a) { (+^ $a) + 1 }
say ²^ 18446744073709551592; # 24
My original "semi-educated wild guess"² that turned out to be acceptable to #zentrunix and the basis for Liz's op:
say (+^ my uint $ = 18446744073709551592) + 1; # 24
\o/ It works!³
Footnotes
¹ I flipped the two character op because I wanted to follow the +^ form, have it sub-vocalize as "two's complement", and avoid it looking like ^2.
² One line of thinking was about the particular integer. I saw that 18446744073709551592 is close to 2**64. Another was that integers are limited precision in Perl unless you do something to make them otherwise, whereas in Raku they are arbitrary precision unless you do something to make them otherwise. A third line of thinking came from reading the doc for prefix +^ which says "converts the number to binary using as many bytes as needed" which I interpreted as meaning that the representation is somehow important. Hmm. What if I try an int variable? Overflow. (Of course.) uint? Bingo.
³ I've no idea if this solution is right for the wrong reasons. Or even worse. One thing that's concerning is that uint in Raku is defined to correspond to the largest native unsigned integer size supported by the Raku compiler used to compile the Raku code. (Iirc.) In practice today this means Rakudo and whatever underlying platform is being targeted, and I think that almost certainly means C's uint64_t in almost all cases. I imagine perl has some similar platform dependent definition. So my solution, if it is a reasonable one, is presumably only portable to the degree that the Raku compiler (which in practice today means Rakudo) agrees with the perl binary (which in practice today means P5P's perl) when run on some platform. See also #p6steve's comment below.
'Long-hand' answer:
raku -e 'put ( (18446744073709551592.base(2) - 0b1).comb.map({!$_.Int+0}).join.parse-base(2));'
OR
raku -e 'say 18446744073709551592.base(2).comb.map({!$_.Int+0}).join.parse-base(2) + 1;'
Sample Output: 24
The answers above (should?) implement "Two's-Complement" encoding directly. Neither uses Raku's +^ twos-complement operator. The first one subtracts one from the binary representation, then inverts. The second one inverts first, then adds one. Neither answer feels truly correct, yet the same answer as Perl5 is obtained (24).
Looking at the Raku Docs page, one would conclude that the "twos-complement" of a positive number would be negative, hence it's not clear what the Perl (and now Raku) answers represent. Hopefully the foregoing is somewhat useful.
https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT
I have some script, that upon execution returns something like this:
1 - some option
2 - nice option
3 - bad option
4 - other option
What number do you choose?
and it is waiting for the feedback. I want expect to parse this text and always respond with a digit assigned to nice option. The script might change, so sometimes it might be that nice option is a option number 2, sometimes it might be option number 4. How could I do that?
Right now I am doing something like this:
expect -c 'spawn script.sh
set timeout 3600
expect "What number do you choose?"
send "2\r"
expect eof'
But if the script will change and nice option will not be under number 2, then I will have a problem.
I believe that I found the solution, using only expect:
expect -c 'spawn script.sh
expect -re {(\d)\ - nice option}
send "$expect_out(1,string)\r"
expect eof
expect -re will match using regular expression ( \d means "any digit"). Because \d is in capturing group or in other words, in parentheses it is saved in regular expression capturing group number 1 (regexp tutorial link). In expect you can reference up to 9 regex capturing groups, outside of this regex, and they are saved in $expect_out(1,string), $expect_out(2,string) etc up to $expect_out(9,string) (Google Books link). So if we use $expect_out(1,string) instead of $expect_out(0,string) we will send only the digit part that get matched in regexp, instead of whole string that would $expect_out(0,string) return.
In the ANTLRv4 grammar that one can find in the grammars-v4 repository (https://github.com/antlr/grammars-v4/blob/master/antlr4/ANTLRv4Parser.g4) the optional rule ebnfSuffix is:
sometimes matched using ebnfSuffix?, see lexerElement
sometimes matched using (ebnfSuffix | ), see element.
I was indeed asking to myself, and here as well, if the two have slightly different meaning.
The grammars-v4 repository has another example in https://github.com/antlr/grammars-v4/blob/master/cql3/CqlParser.g4 of the same two patterns with respect to beginBatch rule used has optional element or together with an empty alternative.
EDIT: I've added here the part of the grammar I'm referring to as suggested:
lexerElement
: labeledLexerElement ebnfSuffix? <-- case 1: optional rule
| lexerAtom ebnfSuffix?
| lexerBlock ebnfSuffix?
| actionBlock QUESTION?
;
element
: labeledElement (ebnfSuffix |) <-- case 2: block with empty alternative
| atom (ebnfSuffix |)
| ebnf
| actionBlock QUESTION?
;
Both ebnfSuffix? and (ebnfSuffix | ) result in exactly the same behaviour: they (greedily) optionally match ebnfSuffix.
The fact that they're both being used in a grammar could be because it was translated from some spec (or other grammar) that used that notation and that notation didn't have the ? operator, but that's just guessing.
Personally I'd just use ebnfSuffix?.
I have a grammar with some ambuguities I need to resolve.
One of the rules takes the following form:
TArg:
anys=Anys
| rnumb1=PNumb ".." (rnumb2=PNumb)?
;
Or this image, if you prefer
The rule Anys has the potential to start with a PNumb. I can see where the ambiguity is, but how to I tell XText to take the second path if it sees a PNumb followed by the double dot?
Presumably, if I use
TArg:
(=> rnumb1=PNumb ".." (rnumb2=PNumb)?)
|anys=Anys
;
Then it will always choose the first if it sees a number, regargless of if it sees the "..", and I will run into problems.
What is the correct usage/placement of the syntactic predicate here to allow Antlr to look ahead to see if the ".." is present?
Cheers in advance.
You need to also include the '..'
TArg:
=>(rnumb1=PNumb "..") (rnumb2=PNumb)?
| anys=Anys
;
I have a DCL script that creates a .txt file that looks something like this
something,somethingelse,00000004
somethingdifferent,somethingelse1,00000002
anotherline,line,00000015
I need to sort the file by the 3rd column highest to lowest
ex:
anotherline,line,00000015
something,somethingelse,00000004
somethingdifferent,somethingelse1,00000002
Is it best to use the sort command, if so everything i've seen required a position number, how can this be done if each line would have a different start position?
If sort is a bad way to handle this is there something else or can I somehow handle this while writing the lines to the file.
I've only been working with VMS/DCL for a few weeks now so i'm not fimilar with all of the commands yet.
Thanks!
As you already noticed, the VMS sort expects fields with a fixed start position within a record. You can not specify a field by a separator. If you want to use the VMS sort you have to make sure your third field starts at the same column, for all records. In other words, you have to pad preceding fields. If you have control on how the file is created, this may work for you. If you don't or you don't know how big the string in front of the sort field will be, this may not be a workaround. Maybe changing the order of the fields is an option.
On the other hand, you may find GNV installed on your system. Then you can try to use its sort, which is a GNU style sort. That is, $ mcr gnv$gnu:[bin]sort -t, -k3 -r x.txt may get you the wanted results.
VMS Sort is indeed not really equipped for this.
Reformatting as you did is about the only way.
If you so not have access to GNV sort on the OpenVMS system then perhaps you have, or can install PERL? Is is somewhat easier to install.
In perl there are of course many ways.
For example using an anonymous sort function ( $a is first arg, $b second; <> reads all input )
$ perl -e "print sort { 0+(split /,/,$b)[1] <=> 0+(split /,/,$a)[2]} <>" x.x
where the 0 + forces numeric evaluation. For (fixed length?) string compare use:
$ perl -e "print sort { (split /,/,$b)[2] cmp (split /,/,$a)[2]} <>" x.x
hth,
Hein.enter code here