How can I convert this BNF to EBNF?
<vardec> ::= var <vardeclist>;
<vardeclist> ::= <varandtype> {;<varandtype>}
<varandtype> ::= <ident> {,<ident>} : <typespec>
<ident> ::= <letter> {<idchar>}
<idchar> ::= <letter> | <digit> | _
EBNF or Extended Backus-Naur Form is ISO 14977:1996, and is available in PDF from ISO for free*. It is not widely used by the computer language standards. There's also a paper that describes it, and that paper contains this table summarizing EBNF notation.
Table 1: Extended BNF
Extended BNF Operator Meaning
-------------------------------------------------------------
unquoted words Non-terminal symbol
" ... " Terminal symbol
' ... ' Terminal symbol
( ... ) Brackets
[ ... ] Optional symbols
{ ... } Symbols repeated zero or more times
{ ... }- Symbols repeated one or more times†
= in Defining symbol
; post Rule terminator
| in Alternative
, in Concatenation
- in Except
* in Occurrences of
(* ... *) Comment
? ... ? Special sequence
The * operator is used with a preceding (unsigned) integer number; it does not seem to allow for variable numbers of repetitions — such as 1-15 characters after an initial character to make identifiers up to 16 characters long. This lis
In the standard, open parenthesis ( is called start group symbol and close parenthesis ) is called end group symbol; open square bracket [ is start option symbol and close square bracket is end option symbol; open brace { is start repeat symbol and close brace } is end repeat symbol. Single quotes ' are called first quote symbol and double quotes " are second quote symbol.
* Yes, free — even though you can also pay 74 CHF for it if you wish. Look at the Note under the box containing the chargeable items.
The question seeks to convert this 'BNF' into EBNF:
<vardec> ::= var <vardeclist>;
<vardeclist> ::= <varandtype> {;<varandtype>}
<varandtype> ::= <ident> {,<ident>} : <typespec>
<ident> ::= <letter> {<idchar>}
<idchar> ::= <letter> | <digit> | _
The BNF is not formally defined, so we have to make some (easy) guesses as to what it means. The translation is routine (it could be mechanical if the BNF is formally defined):
vardec = 'var', vardeclist, ';';
vardeclist = varandtype, { ';', varandtype };
varandtype = ident, { ',', ident }, ':', typespec;
ident = letter, { idchar };
idchar = letter | digit | '_';
The angle brackets have to be removed around non-terminals; the definition symbol ::= is replaced by =; the terminals such as ; and _ are enclosed in quotes; concatenation is explicitly marked with ,; and each rule is ended with ;. The grouping and alternative operations in the original happen to coincide with the standard notation. Note that explicit concatenation with the comma means that multi-word non-terminals are unambiguous.
† Casual study of the standard itself suggests that the {...}- notation is not part of the standard, just of the paper. However, as jmmut notes in a comment, the standard does define the meaning of {…}-:
§5.8 Syntactic term
…
When a syntactic-term is a syntactic-factor followed by
an except-symbol followed by a syntactic-exception it
represents any sequence of symbols that satisfies both of
the conditions:
a) it is a sequence of symbols represented by the syntactic-factor,
b) it is not a sequence of symbols represented by the
syntactic-exception.
…
NOTE - { "A" } - represents a sequence of one or more A's because it is a syntactic-term with an empty syntactic-exception.
Remove the angle brackets and put all terminals into quotes:
vardec ::= "var" vardeclist;
vardeclist ::= varandtype { ";" varandtype }
varandtype ::= ident { "," ident } ":" typespec
ident ::= letter { idchar }
idchar ::= letter | digit | "_"
Related
I'm trying to convert filenames to remove unacceptable characters, but tr doesn't always treat its input arguments exactly as they're given.
For example:
$ echo "(hello) - {world}" | tr '()-{}' '_'
_______ _ _______
...whereas I only intended to replace (, ), -, { and }, all the characters between ) and { in ASCII collation order were replaced as well -- so every letter in the input also became a _!
Is there a way to make tr replace only the exact characters given in its argument?
tr's syntax is surprisingly complicated. It supports ranges, character classes, collation-based equivalence matching, etc.
To avoid surprises (when a string matches any of that syntax unexpectedly), we can convert our literal characters to a string of \### octal specifiers of those characters' ordinals:
trExpressionFor() {
printf %s "$1" | od -v -A n -b | tr ' ' '\\'
}
trL() { # name short for "tr-literal"
tr "$(trExpressionFor "$1")" "$(trExpressionFor "$2")"
}
...used as:
$ trExpressionFor '()-{}'
\050\051\055\173\175
$ echo "(hello) - {world}" | trL '()-{}' '_'
_hello_ _ _world_
Below is a simplified model of what I'm trying to achieve:
#!bin/ksh
string=AUS00
case $string in
[[:alnum:]] ) echo "alphanumeric" ;;
*) echo "nope" ;;
esac
I'm unable to validate alphanumeric code.
Constraints:
The validation need to happen inside the case statement
alnum function is not supported
Positive check only. Can't check for the absence of alphanumeric.
Thank you very much
The pattern [[:alnum:]] will match a single alphanumeric character. Your string is longer than one character, so it won't match.
If you want to check that your string contains an alnum character, you want *[[:alnum:]]*
If you want to check that your string only contains alnum characters, I'd flip the check to see if the string contains a non-alnum character:
for string in alnumOnly 'not all alnum'; do
case "$string" in
*[^[:alnum:]]*) echo "$string -> nope" ;;
*) echo "$string -> alphanumeric" ;;
esac
done
alnumOnly -> alphanumeric
not all alnum -> nope
I realized that ksh (even ksh88) implements what bash describes as "extended patterns":
A pattern-list is a list of one or more patterns separated
from each other with a |. Composite patterns can be formed
with one or more of the following:
?(pattern-list)
Optionally matches any one of the given patterns.
*(pattern-list)
Matches zero or more occurrences of the given
patterns.
+(pattern-list)
Matches one or more occurrences of the given patterns.
#(pattern-list)
Matches exactly one of the given patterns.
!(pattern-list)
Matches anything, except one of the given patterns.
So we can do:
case "$string" in
+([[:alnum:]]) ) echo "$string -> alphanumeric" ;;
* ) echo "string -> nope" ;;
esac
I'm using JavaCC to make a specification to recognize a language. The problem I have is that JavaCC gives me a warning because public is a common prefix of Member() declaration. Member() can has Attributes() and/or Method() but must have at least one Method, the order does not matter.
The warning JavaCC gives me is:
Choice conflict in (...)+ construct at line 66, column 23.
Expansion nested within construct and expansion following construct have common prefixes, one of which is: "public". Consider using a lookahead of 2 or more for nested expansion.
The line 66 is the only line of Member(). Also I need to do this without change lookahead value.
Here is the code:
void Member() : {}
{
(Attribute())* (Method())+ (Attribute() | Method())*
}
void Attribute() : {}
{
"private" Type() <Id> [":=" Expr()]";"
}
void Method() : {}
{
MethodHead() MethodBody()
}
void MethodHead() : {}
{
("public")? (<Id> | Type() | "void") <Id> "(" Parameter() ")"
}
Thanks.
The problem is that this regular expression
(Method())+ (Attribute() | Method())*
is ambiguous. Let's abbreviate methods by M and attributes by A. If the input is MAM, there no problem. The (Method())+ matches the first M and the (Attribute() | Method())* matches the remaining AM. But if the input is MMA, where should the divide be? Either (Method())+ matches M and (Attribute() | Method())* matches MA or (Method())+ matches MM and (Attribute() | Method())* matches A. Both parses are possible. JavaCC doesn't know which parse you want, so it complains.
What you can do:
Nothing. Ignore the warning. The default behaviour is that as many Methods as possible will be recognized by (Method())+ and only methods after the first attribute will be recognized by (Attribute() | Method())*.
Suppress the warning using lookahead. You said you don't want to add lookahead, but for completeness, I'll mention that you could change (Method())+ to (LOOKAHEAD(1) Method())+. That won't change the behaviour of the parser, but it will suppress the warning.
Rewrite the grammar.
The offending line could be rewritten as either
(Attribute())* Method() (Attribute() | Method())*
or as
(Attribute())* (Method())+ [Attribute() (Attribute() | Method())*]
I need a regular expression which can match a string with the following requirements:
Must be between 6 and 64 characters long
Cannot include the following symbols : #, &, ', <, >, !, ", /, #, $, %, +, ?, (, ), *, [ , ] , \ , { , }
Cannot contain spaces, tabs, or consecutive underscores, i.e. __
Cannot contain elements that imply an email address or URL, such as ".com", ".net", ".org", ".edu" or any variation (e.g. "_com" or "-com")
Cannot start with underscore '_', dash '-' or period '.'
Cannot contain the words "honey" or "allied"
Cannot contain single letter followed by numbers
This is better done with several regular expressions! And some of your conditions don't even need regexes (in fact, they would be counter productive).
use a string length function
use a function looking up for that character in your string;
match against _{2,} and \s
match against [._-](?:com|net|....)
use a string function looking for these characters at the first position, or ^[-._]
whole words? What about "calliedaaa"? If whole words, match against \b(?:honey|allied)\b, otherwise use a string lookup function
match against \w\d+
So basically I want to parsed structure CSS code in PHP, using a lexer/parser generated by the PEAR packages PHP_LexerGenerator and PHP_ParserGenerator. My goal is to parse files like this:
selector, selector2 {
prop: value;
prop2 /*comment */ :
value;
subselector {
prop: value;
subsub { prop: value; }
}
}
This is all fine as long as I don't have pseudo classes. Pseudoclasses allow it, to add : and a CSS name ([a-z][a-z0-9]*) to an element, like in a.menu:visited. Being somewhat lazy, the parser has no list of valid pseudo classes and accepts everything for the class name.
My grammar (ignoring all the special cases and whitespace) looks like this:
document ::= (<rule>)*
rule ::= <selector> '{' (<content>)* '}'
content ::= <rule>
content ::= <definition>
definition ::= <name> ':' <name> ';'
// h1 .class.class2#id :visited
<selector> ::= <name> (('.'|'#') <name>)* (':' <name>)?
Now, when I try to parse the following
h1 {
test:visited {
simple: case;
}
}
The parser complains, that it expected a <name> to follow the double colon. So it tries to read the simple: as a <selector> (just look at the syntax highlighting of SO).
Is it my error that the parser can not backtrace enough to try the <definition> rule? Or is Lemon just not powerful enough to express this? If so, what can I do to get a parser working with this grammar?
Your question asks about PHP_ParserGenerator and PHP_LexerGenerator. The parser generator code is marked as 'not maintained', which bodes ill.
The syntax you are using for the grammar is not acceptable for Lemon, so you need to clarify why you think the parser generator should accept it. You mention a problem with 'expected a <name> to follow the double colon, but neither your grammar nor your sample input has a double colon, which makes it hard to help you.
I think this Lemon grammar is equivalent to the one you showed:
document ::= rule_list.
rule_list ::= .
rule_list ::= rule_list rule.
rule ::= selector LBRACE content_list RBRACE.
content_list ::= .
content_list ::= content_list content.
content ::= rule.
content ::= definition.
definition ::= NAME COLON NAME SEMICOLON.
selector ::= NAME opt_dothashlist opt_colonname.
opt_dothashlist ::= .
opt_dothashlist ::= dot_or_hash NAME.
dot_or_hash ::= DOT.
dot_or_hash ::= HASH.
opt_colonname ::= COLON NAME.
However, when it is compiled, Lemon complains 1 parsing conflicts and the output file shows:
State 2:
definition ::= NAME * COLON NAME SEMICOLON
selector ::= NAME * opt_dothashlist opt_colonname
(10) opt_dothashlist ::= *
opt_dothashlist ::= * dot_or_hash NAME
dot_or_hash ::= * DOT
dot_or_hash ::= * HASH
COLON shift 10
COLON reduce 10 ** Parsing conflict **
DOT shift 13
HASH shift 12
opt_dothashlist shift 5
dot_or_hash shift 7
This means it is not sure what to do with a colon; it might be the 'opt_colonname' part of a 'selector' or it might be part of a 'definition':
name1:name4 : name2:name3 ;
Did you mean to allow syntax such as that? Nominally, according to the grammar, that should be valid, but
name1:name4;
should also be valid. I think it requires 2 or 3 lookahead tokens to disambiguate these (so your grammar is not LALR(1) but LALR(3)).
Review your definition of 'selector' in particular.