Add Proposal | Add Analysis | Edit Class, Environment, or Release |
Number | 203
|
Category | errata
|
Synopsis | A.1.4: list_of_port_declarations BNF rule
|
State | open
|
Class | errata-discuss
|
Arrival-Date | Nov 19 2002
|
Originator | Dennis Marsa <drm@xilinx.com>
|
Release | 2001b: A.1.4
|
Environment |
|
Description |
The following BNF rule from section A.1.4 describes the syntax for new-style port lists: list_of_port_declarations ::= "(" port_declaration { "," port_declaration } ")" | "(" ")" This rule should be modified to remove the second alternative, leaving just: list_of_port_declarations ::= "(" port_declaration { "," port_declaration } ")" A port list of the form "(" ")" should be treated as an old-style port list, whose syntax is already defined by the BNF rule "list_of_ports". See the thread beginning with: http://boydtechinc.com/etf/archive/etf_2002/0543.html for additional information. |
Fix |
|
Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule Date: Sun, 24 Nov 2002 14:39:46 +0200 What does this do to the decision on #155, to delete the [] around list_of_ports, but leave them on list_of_port_declarations ? That decision caused a module declaration with no port list (i.e., no parentheses) to be parsed "as though" it were a new-style port list. The reasoning was that it syntactically restricted the following statements to non_port_module_item instead of just module_item. But what logic is there to treat the "no port list" and "empty port list" cases differently? In the empty port list case, you also may not have port declarations within the module! Maybe it is better to make them consistent with each other? A third possiblity would be to break out the "no port list" case explicitly to a separate production, and remove the brackets around both list_of_ports and list_of_port_declarations. Shalom > The following BNF rule from section A.1.4 describes the syntax > for new-style port lists: > > list_of_port_declarations ::= > "(" port_declaration { "," port_declaration } ")" > | "(" ")" > > This rule should be modified to remove the second alternative, > leaving just: > > list_of_port_declarations ::= > "(" port_declaration { "," port_declaration } ")" > > A port list of the form "(" ")" should be treated as > an old-style port list, whose syntax is already defined > by the BNF rule "list_of_ports". From: Dennis Marsa <drm@xilinx.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule Date: Mon, 25 Nov 2002 09:08:28 -0700 Shalom Bresticker wrote: > > What does this do to the decision on #155, > to delete the [] around list_of_ports, but leave them on > list_of_port_declarations ? > > That decision caused a module declaration with no port list > (i.e., no parentheses) to be parsed "as though" it were a new-style port > list. > > The reasoning was that it syntactically restricted the following > statements > to non_port_module_item instead of just module_item. > > But what logic is there to treat the "no port list" and "empty port > list" cases differently? > > In the empty port list case, you also may not have port declarations > within the module! Let's be careful describing "()" as the "empty port list". It is not empty. It has one anonymous, internally unconnected port. I don't know if there is a good term to accurately describe "()". You're right that a module with a () port list cannot contain port declarations, but its not the only possible old-style port list with that restriction: Consider: module (,); // 2 anonymous ports module (,,); // 3 anonymous ports module (,,,); // 4 anonymous ports etc. ... Dennis From: Shalom.Bresticker@motorola.com To: Dennis Marsa <drm@xilinx.com> Cc: etf-bugs@boyd.com Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule Date: Mon, 25 Nov 2002 22:02:16 +0200 (IST) > You're right that a module with a () port list cannot contain port > declarations, but its not the only possible old-style port list with > that restriction: Consider: > > module (,); // 2 anonymous ports > module (,,); // 3 anonymous ports > module (,,,); // 4 anonymous ports etc. > ... All true, but 1. That does not change my point. 2. In contrast to (), I have never seen (,) and I believe I never will. I do not consider that an interesting case. |
Unformatted |
|
Hosted by Boyd Technology