Advantages of denying keywords as identifiers

Discussion in 'VHDL' started by valentin tihomirov, Dec 17, 2004.

  1. 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?
     
    valentin tihomirov, Dec 17, 2004
    #1
    1. Advertising

  2. 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?
    >
    >
     
    Mike Treseler, Dec 20, 2004
    #2
    1. Advertising

  3. > 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?
     
    valentin tihomirov, Dec 20, 2004
    #3
  4. valentin tihomirov

    David Koontz Guest

    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?
    >>
    >>
     
    David Koontz, Dec 20, 2004
    #4
  5. 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
     
    Mike Treseler, Dec 20, 2004
    #5
  6. valentin tihomirov

    Jerry Coffin Guest

    > 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.
     
    Jerry Coffin, Dec 20, 2004
    #6
  7. > 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, Dec 22, 2004
    #7
  8. > 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.
     
    valentin tihomirov, Dec 28, 2004
    #8
  9. 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
     
    Mike Treseler, Dec 28, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vbMark
    Replies:
    0
    Views:
    299
    vbMark
    Dec 7, 2006
  2. Sameer
    Replies:
    3
    Views:
    900
    Manish Pandit
    Oct 3, 2007
  3. Penguini
    Replies:
    2
    Views:
    1,461
    Penguini
    Dec 3, 2007
  4. Replies:
    1
    Views:
    369
    Roedy Green
    Apr 22, 2008
  5. Andre Nathan

    Denying access to methods on DRb

    Andre Nathan, Dec 31, 2003, in forum: Ruby
    Replies:
    7
    Views:
    164
    Eric Hodel
    Jan 4, 2004
Loading...

Share This Page