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

Steven,

Gee, thanks for the grammar lesson.

My real point was that there was insufficient care and formality given 
to the BNF in the 2001 spec to be able to authoritatively conclude 
either interpretation. But then again, my major concern isn't whether 
the 2001 spec does or doesn't allow a config to appear in Verilog 
source. My major concern is that the config keywords remain in the 
keyword list for the upcoming 1364 specification. Whether the reason for 
doing so is that configs are intended to be in Verilog source today, 
whether it's to reserve that capability for the future, or whether its 
for the frankly insightful reason you mentioned below (minus the 
extended identifier silliness) isn't nearly as important to me (OK, I do 
prefer the 1st but I'm pragmatic).

Other messages in this thread have suggested that configs were, in fact, 
intended to be part of Verilog source files. I guess you're arguing that 
this was botched and, rather than fix it for the next version of the 
spec, you'd like to drop it. Is this your position?

-randy.

Steven Sharp wrote:

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