Re: [sv-bc] Keywords

Michael McNamara wrote:

>-- On Apr 26 2005 at 00:02, Kevin Cameron sent a message:
> > To: sv-bc@eda.org
> > Subject: "[sv-bc] Keywords"
> > 
> > 
> > Just as a matter of interest: whose compilers can't handle limited
> > context keywords?
> > 
> > I usually write recursive descent parsers that can handle tokens
> > being keywords or not depending on context. It seems that life
> > would be easier if "keyword status" could be limited to particular
> > scopes for particular words e.g. there is no good reason that
> > keywords for configuration should have any special meaning outside
> > of a config block.
> > 
> > Kev.
>
>In truth to handle Verilog 1364-1995 one must implement a context
>sensitve parser (or at least a context sensitive lexer) as items in a
>udp transistion table ( 'r' 'f' 'x'... ) are keywords ONLY in tables;
>else where they can be used as module names, variable names, et
>cetera.
>
>And lex & flex support context sensitive parsing just fine.
>
>
>But in truth the real issues with context sensitive keywords are
>elsewhere:
>
>  - with the human, who is not as good remembering that there was some
>  keyword 10k bytes back that made 'xyzzy' a keyword now, where as
>  usualy one would be free to use it as a variable name...
>
>  - with language specific editors (shameless plug: anyone ever use
>  the verilog-mode for emacs, available at <http://www.verilog.com> ?). 
>  When coding these, it is trivial to tell the editor to always
>  embolden 'module' and 'initial'.  It is real difficult to tell them
>  to only do this when in certain contexts. Where it can be done
>  (emacs) the result is a large decrease in performance.
>
>The two horns of this dilemma are, on the right: please don't steal
>more keywords from the user!  On the left: Please don't confuse the
>user by many context sensitive meanings!
>
>Note that use of keywords like 'default' that get different meanings
>in different contexts is a rather nice exception. In truth this works
>becuase consistantly default always has a consistant meaning: "Do the
>obvious thing".  If it had radically different meetings in other
>contexts this would fail to be useful.
>  
>
We could consider "old" (pre-SystemVerilog) keywords as globally reserved
for backward compatibility, while new keywords are limited in scope.

Cliff's suggestion that possible keyword clashes can be flagged by the 
compiler
could be implemented to warn the user that there is usage that may confuse
some tools (like your emacs mode). You could always use a "treat warnings
as errors" mode if you want to be strict about it.

I think when short common words like "with" have become reserved but are
only used in one type of statement, life can become unnecessarily 
awkward for
folks trying to reuse old code.

>In case blocks, default is what is selected if nothing else
>matches. In config blocks, again default specifies where to look for
>modules that don't match anyother rule.  Selecting from already
>existing reseved words for a very similar conceptual meaning to apply
>in a new context is very good.  Choosing to reserve a short, common
>english word in the entire language for a token that can only be used
>in a very limited context is bad.
>
>Kev: I hope the AMS efforts you are working on will approach the
>keyword issue with these thoughts in mind.
>  
>
That's why I'm raising the issue now, there are more keywords in Verilog-AMS
and some usage clashes. There is an existing user base for Verilog-A/MS that
won't be happy rewriting their code to avoid SystemVerilog syntax issues.

Kev.

>-mac
>
>
>  
>