Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I discovered it doing some parsing. I have also noticed that I cannot
parse the bit string literals because
bit_string_literal ::= [ integer ] base_specifier " [ bit_value ] "
Please note that bit_value is enclosed into the quotes.
bit_value ::= graphic_character { [ underline ] graphic_character }
graphic_character ::= basic_graphic_character | lower_case_letter |
other_special_character
basic_graphic_character ::=
upper_case_letter | digit | special_character | space_character
where special characters are " # & ' () * + , - . / : ; < = > ? @ [ ] _
` -- Please note that the first special character is exactly the
quotation mark. Such definition makes the bit_string_literal closing
literal a part of the literal itself and parser runs into the end of
stream. How do you handle such cases?
I discovered it doing some parsing. I have also noticed that I cannot
parse the bit string literals because
bit_string_literal ::= [ integer ] base_specifier " [ bit_value ] "
Please note that bit_value is enclosed into the quotes.
bit_value ::= graphic_character { [ underline ] graphic_character }
graphic_character ::= basic_graphic_character | lower_case_letter |
other_special_character
basic_graphic_character ::=
upper_case_letter | digit | special_character | space_character
where special characters are " # & ' () * + , - . / : ; < = > ? @ [ ] _
` -- Please note that the first special character is exactly the
quotation mark. Such definition makes the bit_string_literal closing
literal a part of the literal itself and parser runs into the end of
stream. How do you handle such cases?
So you are trying to write a parser for VHDL? Obviously you scan the
input text until you encounter another quote character.
I know some
languages allow quotes to be embedded in strings by using two quotes in
a row, so the scanning is not so simple. You have to scan for a quote
followed by a character that is not a quote. But I don't think VHDL
does this.
So you are trying to write a parser for VHDL? Obviously you scan the
input text until you encounter another quote character.
Obviously, I am doing quite the opposite thing. I follow the grammar
rules instead of scanning for the second mark. I have failed exactly
because not following this simplistic approach. Probably I am the only
one on the planet who does not do that.
I know some
languages allow quotes to be embedded in strings by using two quotes in
a row, so the scanning is not so simple. You have to scan for a quote
followed by a character that is not a quote. But I don't think VHDL
does this.
The duplication of quotation mark is stipulated in the `string_literal`
chapter in LRM. It is also interesting how good this stipulation matches
with the grammar rules, presented in parallel. Yet, I do not see such a
remark in the `bit_string_literal` rule, discussed separately in the LRM.
I looked into example parser,
https://sourceforge.net/p/zamiacad/code/ci/master/tree/src/org/zamia/vhdl/vhdl2008/VHDL2008.jj.
They simply throw the quotation mark out of the special character list
and then add it separately as an alternative to graphic_character in the
string_literal definition. But they do not supply " char in the bit
string definition, which means that they do not support " in the
bitstring literals.
I am looking to know how it is supposed to be done and what does VHDL
community does.
Also note the definition of a string literal is:
string_literal ::= " { graphic_character } "
You would have the same issue here trying to insert a " into a string.
You would have the same issue here trying to insert a " into a string.
Where did you read about that?
Also note the definition of a string literal is:
string_literal ::= " { graphic_character } "
You would have the same issue here trying to insert a " into a string.
Yes, I reported that already to the rickman. I reported that I have
discovered that LRM mandates user to duplicate the double quote marks in
the VHDL source string literals to produce a single quotation in the
running program. The Bible says so textually but LRM grammar productions
seem to contradict the text. LRM does not even stipulate this issue in
the bit_string_literal declaration at all. So I wonder, how did you know
that \" must be used there instead of quotation duplication? Did you
confuse user input with mine parser code, written in derivative of C?
Except you showed BNF for "bit_string_literal" while the double quote
only had meaning in the more literal "string_literal".
Is the
"string_literal" defined the same way?
If your problem is in the
"bit_string_literal" why are you trying to embed quotes in it?
Except you showed BNF for "bit_string_literal" while the double quote
only had meaning in the more literal "string_literal".
Who says that any why does LRM say otherwise? I have demonstrated the
grammar that says that all special characters, including the quotes, are
allowed in the bit string literal, in the same way as they are included
in the string literal.
Is the
"string_literal" defined the same way?
You are responding under KJ's remark saying that the string literal
string_literal ::= " { graphic_character } "
is defined the same way. So, I do not understand this the question.
If your problem is in the
"bit_string_literal" why are you trying to embed quotes in it?
Because I tried to implement the spec rather than my fantasies or to
embed the quotes into the string. I think that if spec admits embedded
quotes, they must be supported.
You mean you tried to implement the BNF which seems to not describe the
language 100%.The VHDL spec is more than just the BNF lists.
To think that a bit literal can contain every letter of
the alphabet is a bit silly.
They can't because a bit string literal
only has meaning when it contains the few characters that are allowed.
You mean you tried to implement the BNF which seems to not describe the
language 100%.The VHDL spec is more than just the BNF lists.
Yes, I tried. Yes, BNF is incomplete and water is liquid. But the
problem that I address here is that BNF seems to contain a fatal error.
Saying that I see it because it does not specify the language 100% is a
little bit inappropriate, isn't it? It is like if instruction to go
shopping would instruct you to kill youself at one point. You may defend
the instruction saying that "it is incomplete" but this would make the
situation even more ridiculous. And it does.
To think that a bit literal can contain every letter of
the alphabet is a bit silly.
What if BNF admits every character? Have you ever looked at the
appropriate lines I have copy pasted before starting to teach me? I do
not need to learn the kid stuff. I have a concrete question and need to
know where is the error concretely.
They can't because a bit string literal
only has meaning when it contains the few characters that are allowed.
Any user-defined literal or identifier falls into this category.
Everything that user defines must consist solely of few allowed
characters. But, it is again as informative as "the water is wet" above.
Simply saying "only permitted characters make sense" does not point us
to which of the characters are permitted exactly, isn't it?
Can you stop speaking misteriously with insinuations, and start telling
exactly which characters are defined legit in LRM. I do not tolerate
when people ignore my questions or draw them into 0-information, I hate
intellectual pretense and not going to learn trivial, obvious things.
You mean you tried to implement the BNF which seems to not describe the
language 100%.The VHDL spec is more than just the BNF lists.
Yes, I tried. Yes, BNF is incomplete and water is liquid. But the
problem that I address here is that BNF seems to contain a fatal error.
Saying that I see it because it does not specify the language 100% is a
little bit inappropriate, isn't it? It is like if instruction to go
shopping would instruct you to kill youself at one point. You may defend
the instruction saying that "it is incomplete" but this would make the
situation even more ridiculous. And it does.
To think that a bit literal can contain every letter of
the alphabet is a bit silly.
What if BNF admits every character? Have you ever looked at the
appropriate lines I have copy pasted before starting to teach me? I do
not need to learn the kid stuff. I have a concrete question and need to
know where is the error concretely.
They can't because a bit string literal
only has meaning when it contains the few characters that are allowed.
Any user-defined literal or identifier falls into this category.
Everything that user defines must consist solely of few allowed
characters. But, it is again as informative as "the water is wet" above.
Simply saying "only permitted characters make sense" does not point us
to which of the characters are permitted exactly, isn't it?
Can you stop speaking misteriously with insinuations, and start telling
exactly which characters are defined legit in LRM. I do not tolerate
when people ignore my questions or draw them into 0-information, I hate
intellectual pretense and not going to learn trivial, obvious things.
You mean you tried to implement the BNF which seems to not describe the
language 100%.The VHDL spec is more than just the BNF lists.
Yes, I tried. Yes, BNF is incomplete and water is liquid. But the
problem that I address here is that BNF seems to contain a fatal error.
If you'd like another example of a discrepancy between BNF and the text,
here you go...
Section 5.2.3.1 (General Integer types)
"An implementation may restrict the bounds of the range constraint of
integer types other than type universal_integer. However, an
implementation shall allow the declaration of any integer type whose
range is wholly contained within the bounds -2147483647 and +2147483647
inclusive."
Section 9.3.2 Literals "numeric_literal ::= abstract_literal |
physical_literal Numeric literals include literals of the abstract types
universal_integer and universal_real, as well as literals of physical
types. Abstract literals are defined in 15.5; physical literals are
defined in 5.2.4.1."
But now look at
the BNF. abstract_literals are numeric_literals.
Section 15.5.1: abstract_literal ::= decimal_literal Section 15.5.2:
decimal_literal ::= integer [ . integer ] [ exponent ]
integer ::= digit { [ underline ] digit } exponent ::= E [ + ]
integer | E - integer
Now, where is the minus sign in the BNF? It's not there.
So while the
section that defines integer literals specifically says that -2147483647
is a literal,
the BNF does not support this since there is no way to put
in the minus sign per the BNF. So these two sections of the
specification conflict.
To me, a reasonable interpretation to make is
that since there is a conflict with the specification itself, that there
should be no flagging of an error by a tool if source code adheres to
the narrative but not the BNF.
So the text -1 should be interpreted as an
integer literal. Not all folks agree and they think that the BNF must
trump narrative
On Sun, 27 Dec 2015 17:33:10 -0800, KJ wrote:
If you'd like another example of a discrepancy between BNF and the text,
here you go...
Section 5.2.3.1 (General Integer types)
"An implementation may restrict the bounds of the range constraint of
integer types other than type universal_integer. However, an
implementation shall allow the declaration of any integer type whose
range is wholly contained within the bounds -2147483647 and +2147483647
inclusive."
The term "literal" does not appear here,
snip
More precisely, any such statement is not part of the quoted material. I
haven't found one elsewhere either)
You didn't look too hard. I see you chose to write this before you read the next paragraph that I wrote or the section that I referenced in the specification. Maybe you'll read it this time.
Section 9.3.2 Literals "numeric_literal ::= abstract_literal |
physical_literal Numeric literals include literals of the abstract types
universal_integer and universal_real, as well as literals of physical
types. Abstract literals are defined in 15.5; physical literals are
defined in 5.2.4.1."
Nor does this state that the range of literals covers the entire range of
values.
You've gone off the deep end now. The sections I've cited do establish the range.
So, clearly -1 should be considered a numeric literal.
I think that requires an inference that is not stated in the quoted
passages above.
Now, where is the minus sign in the BNF? It's not there.
Which suggests an alternative inference : only the naturals are
representable as literals; negative values are expressed as the result of
a negation operator on a positive literal.
the BNF does not support this since there is no way to put
in the minus sign per the BNF. So these two sections of the
specification conflict.
The conflict exists only if the former section of the specification
actually exists, which is not established by the quoted material.
The BNF unambiguously parses -1 as [unary operator][literal]. If you
additionally allow negative literals, how do you resolve the resulting
ambiguous parsing?
There is more to the language specification than the BNF. In this
particular case, the following text is relevant (all from VHDL-2008)
Section 15.7 (String literals): "If a quotation mark value is to
be represented in the sequence of character values, then a pair
of adjacent quotation marks shall be written at the corresponding
place within the string literal. (This means that a string literal
that includes two adjacent quotation marks is never interpreted as
two adjacent string literals.)"
There is an example which shows that """" (four consecutive quotation
marks) is a string literal of length 1.
Section 15.8 (Bit String Literals): "A bit string literal has a
value that is a string literal"
If you'd like another example of a discrepancy between BNF and the text, here you go...
Section 5.2.3.1 (General Integer types)
"An implementation may restrict the bounds of the range constraint of integer types other than type
universal_integer. However, an implementation shall allow the declaration of any integer type whose range is wholly contained within the bounds -2147483647 and +2147483647 inclusive."
Section 9.3.2 Literals
"numeric_literal ::= abstract_literal | physical_literal
Numeric literals include literals of the abstract types universal_integer and universal_real, as well as literals of physical types. Abstract literals are defined in 15.5; physical literals are defined in 5.2.4.1."
So, clearly -1 should be considered a numeric literal. But now look at the BNF. abstract_literals are numeric_literals.
Section 15.5.1: abstract_literal ::= decimal_literal
Section 15.5.2: decimal_literal ::= integer [ . integer ] [ exponent ]
integer ::= digit { [ underline ] digit }
exponent ::= E [ + ] integer | E - integer
Now, where is the minus sign in the BNF? It's not there. So while the section that defines integer literals specifically says that -2147483647 is a literal, the BNF does not support this since there is no way to put in the minus sign per the BNF. So these two sections of the specification conflict. To me, a reasonable interpretation to make is that since there is a conflict with the specification itself, that there should be no flagging of an error by a tool if source code adheres to the narrative but not the BNF. The BNF is no more 'correct' than narrative (unless there is such a disclaimer somewhere in the specification that says so). So the text -1 should be interpreted as an integer literal. Not all folks agree and they think that the BNF must trump narrative and think that they are making their tool adhere 'closer' to the standard by using this interpretation when it is convenient...but they are ignoring something specifically called out in the standard. Oh well.
How do you distinguish it from a simple identifier if arguments are not
specified?
On 28.12.2015 3:33, KJ wrote:
Section 15.8 (Bit String Literals): "A bit string literal has a
value that is a string literal"
I have overlooked it indeed.
snip> Now, what does the fact that value is the same as quadrupled '"'
character tell to us? What should the input bit_string_literal look like?
Does LRM stipulate this case? Is it ok? And what should poor compiler do?
Since a " would end up not being a legal bit value when you're all done converting and an error is going to be flagged anyway, I would think a compiler could stop and flag the error at that point.
Uou say that narrative admits the negative integers whereas there is no
way to enter them in BNF. You call it a contradiction but I do not see
any problem here. You simply allocate internal variable of Int type for
every literal that you keep in your tool and do not use the negative
part of it. You will get negatives by applying the "-" operation to the
literal, as Brain pointed out. It is fine.
I do not think that you can treat it equally with the issues that I have
raised.
The double quote and physical unit is simply unparsable.
Well, other tools I assume are able to parse it, although I admit I haven't bothered to try to insert a " into a bit string to see what happens. I'm only giving my take on why the "" appears to be the way to include the " and that the LRM does specify this (in my opinion, maybe not yours)
Yestuday, I have discovered one more conflict of this kind.
function_call ::= name [(args)]
How do you distinguish it from a simple identifier if arguments are not
specified?