RE: [sv-bc] Keywords

-- 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.

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.

-mac