Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Advantages of denying keywords as identifiers

Reply
Thread Tools

Advantages of denying keywords as identifiers

 
 
valentin tihomirov
Guest
Posts: n/a
 
      12-17-2004
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?


 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      12-20-2004
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?
>
>

 
Reply With Quote
 
 
 
 
valentin tihomirov
Guest
Posts: n/a
 
      12-20-2004
> 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?


 
Reply With Quote
 
David Koontz
Guest
Posts: n/a
 
      12-20-2004
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?
>>
>>

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      12-20-2004
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
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      12-20-2004
> 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.

 
Reply With Quote
 
valentin tihomirov
Guest
Posts: n/a
 
      12-22-2004
> 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.


 
Reply With Quote
 
valentin tihomirov
Guest
Posts: n/a
 
      12-28-2004
> 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.


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      12-28-2004
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Binding identifiers to known or unknown identifiers latashag@live.com Java 1 04-22-2008 04:54 AM
Denying access to a JSP page directly Sameer Java 3 10-03-2007 05:10 PM
Need help with denying access to a folder... vbMark ASP .Net 0 12-07-2006 05:27 PM
Trend Firewall is denying access to wireless network. =?Utf-8?B?S2VubnkgRw==?= Wireless Networking 2 03-04-2005 10:29 PM
DriveCrypt Plus Pack for denying entry to your pc urgetoo@korea.com Computer Security 0 07-06-2003 07:39 AM



Advertisments