VHDL Issue Number:      1125
Classification:         Language Definition Problem
Language Version:       VHDL-93
Summary:                Errors and ambiguities in 'path_name and 'instance_name
Related Issues:         
Relevant LRM Sections:  14.1
Key Words and Phrases:  predefined attributes
Current Status:         Submitted
1076-1993 Disposition:  N/A
Disposition Rationale:  N/A
Superseded By:          N/A
-----------------------
Date Submitted:         1997/10/15
Author of Submission:   Peter Ashenden
Author's Affiliation:   University of Adelaide
Author's Post Address:  Dept Computer Science
                        University of Adelaide, SA 5005
                        Australia
Author's Phone Number:  
Author's Fax Number:    
Author's Net Address:   petera@cs.adelaide.edu.au
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.1 $
Date Last Revised:      $Date: 1997/10/15 19:40:08 $


Description of Problem
----------------------

In Chapter 14, in the desriptions of the predefined attributes
'PATH_NAME and 'INSTANCE_NAME:


1. Error in BNF for package_based_path

The example shows that lib.p.proc.x'path_name = ":lib:p:proc:x" (line
463).  This indicates that the intention was for package_based_path to
include the hierarchy of subprogram names in the path of a local
object of a procedure.  This intent is not expressed in the BNF for
the syntax of path names.


2. Ambiguity in BNF rules

There are also ambiguities in the grammar for instance_name and
path_name.  For a component instantiation, block statement, generate
statement, process statement and subprogram, it is not clear whether
the item's simple name should be included as (1) a local_item_name or
(2) a (full_)path_instance_element.  For example, in the following:

        architecture a of e is

          procedure p is ...

        begin ...
        end architecture a;

If the first interpretation is used:

        p'path_name is ":e:p"
        p'instance_name is ":e(a):p"

If the second interpretation is used:

        p'path_name is ":e:p:"
        p'instance_name is ":e(a):p:"

The examples indicate that the second interpretation should be used.
It appears that the intention was that anything that contains a
declarative region should be interpreted as an instance element rather
than as a local item.  However, the examples are non-normative.
Furthermore, if the proposed revision to the rule for
package_based_path (see below) is adopted, then the example path and
instance names for the subprogram proc in the package should be
corrected to include the trailing leader.


3. Problem in instance elements for operator subprograms

The rules for full_path_instance_element and path_instance_element
include subprogram_simple_name for subprograms.  This doesn't deal
with the possibility of a subprogram whose designator is an operator
symbol.


4. No provision for overloaded subprograms

The rules full_path_instance_element and path_instance_element only
include the simple name of an overloaded subprogram.  If there are
overloaded versions of a subprogram, the path name does not
distinguish between them.


5. Inconsistent specification of use of loop label

The rule for full_path_instance_element includes a loop label, but
loops are not mentioned in lines 414-416.  Presumably loop label was
included to all specification of the path to a for loop parameter.
The rule for path_instance_element does not include loop label.


Proposed Resolution
-------------------

1. Revise the BNF rule for package_based_path as shown below.

2. To solve the ambiguity problem, add words to specify that the
simple name of a component instantiation, block statement, generate
statement, process statement or subprogram should be produced as a
path_instance_element or full_path_instance_element, not as a
local_name.  This appears to be the original intent, although it is
not clear from lines 414-416 and 450-452.

3. Generalize instance elements for operator subprograms by replacing
subprogram_simple_name with subprogram_designator.

4. Include an optional signature after subprogram_designator.  The
signature need only be produced if the subprogram is overloaded.  An
implementation could choose to always include the signature, or to
check and only include it if the subprogram is actually overloaded.

5. Add to the paragraph in lines 414-416: "and, if the prefix denotes
a for-loop parameter, for the loop label of the for-loop."  Make the
loop_label optional in the rule for full_path_instance_element (in the
same way that a process_label is optional).  Add a paragraph saying "A
for-loop with no label is denoted by an empty loop label."  Include an
optional loop_label in the rule for path_instance_element. Add to the
paragraph in lines 450-452: "and, if the prefix denotes a for-loop
parameter, for the loop label of the for-loop."

The revised BNF rules are (with invisible italics):

  package_based_path ::=
    leader library_logical_name leader
           package_simple_name leader
           { subprogram_designator [ signature ] leader }
           [ local_item_name ]

  full_path_instance_element ::=
    [ component_instantiation_label @ ]
        entity_simple_name ( architecture_simple_name )
    | block_label
    | generate_label
    | process_label
    | loop_label
    | subprogram_designator [ signature ]

  loop_label ::= [ loop_label ]

  path_instance_element ::=
    component_instantiation_label
    | entity_simple_name
    | block_label
    | generate_label
    | process_label
    | loop_label
    | subprogram_designator [ signature ]


VASG-ISAC Analysis & Rationale
------------------------------
TBD


VASG-ISAC Recommendation for IEEE Std 1076-1993
-----------------------------------------------
TBD


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD