Re: [sv-ec] Re: [sv-bc] potential command line option

Randy,

A lot of the issues here are necessarily matters of opinion and
judgement, and what the current LRM says is only one of the factors
to be considered.  However, it helps to establish any facts that
we can.

You wrote:
>I've tried to go back and divine from where you derive your strong 
>assertion "syntax boxes and BNF clearly specify that they cannot appear 
>in Verilog source files". The best I could come up with is that 
>source_text in A.1.3 and library_text in A.1.1 don't grammatically 
>derive each other. Your view must therefor be that source_text cannot 
>share a file with library_text, correct? I didn't find this restriction 
>anywhere.

This restriction does not have to be spelled out separately, any more
than the rest of the meaning of the BNF notation does.  It follows from
the accepted definitions of formal language theory and the BNF notation.
Note that there is no separate restriction saying that this email is
not valid Verilog source either; that follows in the same way.

A formal language is defined by a formal grammar and a start symbol.
It consists of the set of all strings that can be derived from the
start symbol using the grammar.  The BNF in the LRM fails to specify
the start symbol for Verilog source, though we can deduce from
information outside the BNF that it is source_text.  You could argue
that some other start symbol should be used (thus defining a different
language), and there is nothing in the BNF to contradict it.  However,
there is no start symbol that can be chosen that derives a string
containing both a config and a module.  Therefore we can state with
certainty that no language defined by the BNF allows it.

If someone wanted to define such a language, they could do so by
modifying the BNF to specifically allow it.  This BNF does not.

You might instead be suggesting that when the syntax of a programming
language is specified by a formal language, only a sub-string of the
source input needs to be a valid string in the formal language.  This
is not the accepted convention, and it is easy to see why not.  The
formalism would lose its power to fully specify legal input.  For
example, any input would have to be accepted as Verilog source, since
it contains a legal string as a sub-string (specifically, the empty
string).

>The keywords 
>are already part of the 2001 specification. Whether you view 
>configurations as allowable within a source file or not doesn't create 
>the problem. The problem already exists. The keywords are part of the 
>existing 1364-2001 standard.

While I can come up with some arguments otherwise, I would have to
agree with you that a strict interpretation of the LRM text supports
this.  All of the keywords in Annex B are reserved in both Verilog
source files and library map files.

>In fact, the inclusion of the configuration keywords in a 
>common list of keywords in Appendix B would seem to support the 
>conclusion that both grammars can share a common parse.

If we move from strict interpretation to speculation, there are many
possible conclusions.  Annex B may simply contain a combined list of
keywords from the two different source languages defined in the BNF,
and may not intend to say that all are reserved everywhere.

There is also a reason why you might want to reserve the library map
file keywords in Verilog source files, even though they can never be
used as keywords in a Verilog source file.  If they are not reserved,
then they are valid identifiers that can be used for a module name.
However, that module name could not be referenced in a config, since
it is a keyword there.  Fortunately, it could be referenced by using
the escaped version of the name (since in Verilog, the escaped version
of an identifier is considered to match the non-escaped version, unlike
VHDL).  Once this is recognized, the reason for reserving the keywords
is bypassed.

>I'm quite sympathetic to your motivations 
>of wanting to limit keyword explosion, but this is a bit like trying to 
>close the barn door after the horses have already left, no?

With a strict interpretation of the current LRM, I would describe the
situation as "the barn door is open, but the horses have not left yet,
so we can safely close it".

Reserving a keyword can create a backward compatibility problem.
Unreserving an unused keyword cannot. 

Every program that compiled with the keyword reserved will also compile
with it unreserved.  The only problem is that it allows programs that
will be illegal if you reserve it in the future.  But since the keywords
were not reserved before the 2001 standard, there are already plenty of
such programs.  And having them reserved in the 2001 standard isn't really
helping if most tools aren't enforcing it.

So while the interpretation that configs are not allowed in Verilog
source files does not automatically allow "config" as an identifier in
1364-2001, it means that allowing it as an identifier in 1364-2005 would
be backward compatible with 1364-2001.

Steven Sharp
sharp@cadence.com