RE: [sv-bc] P1800 draft2 review : Sec 9 Processes

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Mon Apr 16 2007 - 06:09:07 PDT
I don't necessarily object. But then it would be wise to see how else
the term 'procedure' is used in the LRM to be sure that it does not
cause a conflict. And it is not just 'construct' that would have to
change as 'always' and 'initial' have various other names in addition to
'construct' in the text.

 

Also see Mantis 1278, which was a 1364 issue, where the proposed
resolution was to use 'construct' consistently.

 

Shalom

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Brad Pierce
Sent: Sunday, April 15, 2007 8:54 PM
To: sv-bc@server.eda-stds.org
Subject: Re: [sv-bc] P1800 draft2 review : Sec 9 Processes

 

>Also, the Formal Syntax  Annex A A.1.4 these are still defined as
initial_construct, final_construct, always_construct

 

Good point.  It would make sense to rename these and define

 

       procedure ::= initial_procedure | always_procedure |
final_procedure

 

and add a footnote in non_port_program_item that it shall be illegal to
use an always_procedure in a program.

 

- Brad

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gran, Alex
Sent: Sunday, April 15, 2007 10:20 AM
To: sv-bc@eda-stds.org
Subject: [sv-bc] P1800 draft2 review : Sec 9 Processes

I had some time so I decided to read through Sec 9 Processes (1364-2005
9.7, 9.8,9.9, 10.3, 1800-2005 10.7 10.10, 11)

 

Here's what I noted.  Most of this stuff is just trying to find
consistency in the terms that are used for certain things, as apposed
any problems with the actual content.

 

~Alex

 

 

 

9.1

    In the list at top of 9.1 'initial' and 'always' are described as
"procedures" not "constructs".  Why is 'final' still a :"construct" not
a procedure?

        Section 9.1.3 refers to these as "final procedure"

 

    Also, the Formal Syntax  Annex A A.1.4 these are still defined as
initial_construct, final_construct, always_construct

        Will this introduce confusion having one term used in he BNF and
a different term used in the descriptive text?  Or will mucking with the
BNF between revisions cause more of a headache?

  


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Apr 16 06:09:39 2007

This archive was generated by hypermail 2.1.8 : Mon Apr 16 2007 - 06:10:12 PDT