Advantages of denying keywords as identifiers

[valentin tihomirov]

I see no advantage in denial using keywords as identifiers; this just
complicates VHDL netlisting automation when adopting non-vhld design. Is it
because yacc/bison like tools have bad support of the case or text editors
could easily highlit keywords basing on lexer rather than parser? Many tools
do not support situations where for example signal name conflicts with
entity name. Does language specification tell anything about this?

 

[Mike Treseler]

valentin tihomirov wrote:

I see no advantage in denial using keywords as identifiers;

Hmmm ...

entity entity is
end entity entity; --?

-- Mike Treseler



this just

complicates VHDL netlisting automation when adopting non-vhld design. Is it
because yacc/bison like tools have bad support of the case or text editors
could easily highlit keywords basing on lexer rather than parser? Many tools
do not support situations where for example signal name conflicts with
entity name. Does language specification tell anything about this?

 

[valentin tihomirov]

Hmmm ...

entity entity is
end entity entity; --?

-- Mike Treseler



this just
complicates VHDL netlisting automation when adopting non-vhld design...

entity entity is
end entity entity; --?

-- Mike Treseler

But the grammar pattern is
designUnit ::= entity | architecture | configureation | ...
entity ::= "entity" ID "is" entityBody "end" "entity" [ID];

I see no reason to prohibit keywords as ID names. IMO, this requirement is
an unjustified redundancy, a complication. Recently, I was playing with the
ANTLR parser generator, it automatically converts grammar rules into
Java/C++ parser class methods. The problem raised specifying rule
"interface". As "interface" is a reserved word in Java, a completely correct
grammar produces incompilable java code. This is what I mean "complicates
VHDL netlisting automation when adopting non-vhld design". Plactically, I
find it more convenient to store automatically processed netlists in EDIF
just becase any identifiers are allowed. So, what is the ground for this
language whim?

 

[Jerry Coffin]

I see no advantage in denial using keywords as identifiers;

Talk to somebody who's written a Fortran parser and see what s/he
thinks -- that is, if you can find one who's still sufficiently sane to
carry on a normal conversation at all...

Seriously, reserving key words makes parsing somewhat easier, and
lexing _drastically_ easier.

It sounds to me like you're trying to warp the entire rest of the
language to fit one fairly special case, at best. This is a poor
tradeoff.

--
Later,
Jerry.

The universe is a figment of its own imagination.

 

[valentin tihomirov]

there'd be lots of ambiguities in VHDL,

Lets't take
plus -> '(' 'plus' ID ID ')'
ID -> ('a'..'z')+
as example languge. I see there is only one parse tree can be built on the
'(plus plus X)' input, thus it is not ambigous.

 

[valentin tihomirov]

I agree that the rule is redundant and may
be a complication for tool makers.

However, it is justified because it eliminates
the possibility that my brain will ever have to parse
and understand code written like the example above.

Netlsting is primarily automation oriented, nobody draws modern circuits in
text today. Nobody forces people to use VHDL keywords as identifiers.
However, why should users account for the whims of storage languages?
Consider a database rejecting SQL statements as data fields -- will you use
it? My brain will not accept such a nonsense.

 

[Mike Treseler]

Netlisting is only one application. VHDL is more commonly used
for high-level design entry and simulation/verification. Catching
logical errors at the text level is a primary advantage of using
an HDL. If I say "entity entity" it is a logical error that I would
like to have flagged before I go any further.

All of the multivendor cae tools can generate
and use EDIF formatted netlists.

-- Mike Treseler

 

[David Koontz]

Mike Treseler wrote:

valentin tihomirov wrote:

I see no advantage in denial using keywords as identifiers;


Hmmm ...

entity entity is
end entity entity; --?

-- Mike Treseler

The idea is to allow context free tokenizing, something hard to do
with the example above.

VHDL can be context free tokenized except for something like:

A(3 downto 0) <= std_logic_vector'('0','0','0','0');

where the initial apostrophe (single quote) can cause and error,
requiring backtracking from finding a character literal '(' to
finding an apostrophe. This was handled by an LRM 93 issue report
1045 ( http://www.eda.org/isac/IRs1k/IR1045.txt ) and requires tracking
only the previous token. An IR1045 compliant tokenizer can be
accomplished in lex, which is also capable of dealing with identifier
character case, without rejecting tokens. Mind you the code isn't
elegant, it can be done faster and smaller in say C without state
transition tables for everything but keyword recognition.

Allowing identifier re-use of keywords could require looking ahead
a large number of tokens to recognize context. This would require
interaction with a symbol table and would make for a larger and
slower tokenizer and/or parser. Syntax highlighting in an editor
would require this monster, there'd be lots of ambiguities in VHDL,
not the least of which that labels are implicitly declared. Even with
the context implied by IR1045 mentioned above, a tokenizer for VHDL
as it is defined can be completely separate from a parser. Most
editors don't allow import of the tokenizer and would be capable of
an IR1045 error, but highlighting is not typically mapped into
something that can show up, allowing the native highlighting
tokenizing method to be used.

this just

complicates VHDL netlisting automation when adopting non-vhld design.
Is it
because yacc/bison like tools have bad support of the case or text
editors
could easily highlit keywords basing on lexer rather than parser? Many
tools
do not support situations where for example signal name conflicts with
entity name. Does language specification tell anything about this?

 

[Mike Treseler]

valentin tihomirov wrote:

entity entity is
end entity entity; --?

-- Mike Treseler


But the grammar pattern is
designUnit ::= entity | architecture | configureation | ...
entity ::= "entity" ID "is" entityBody "end" "entity" [ID];

I see no reason to prohibit keywords as ID names. IMO, this requirement is
an unjustified redundancy, a complication.

I agree that the rule is redundant and may
be a complication for tool makers.

However, it is justified because it eliminates
the possibility that my brain will ever have to parse
and understand code written like the example above.

-- Mike Treseler