(r2) LCS2016_I03 < P1076

P1076 Web>VHDL2017>LCS2016_I03 (revision 2) (raw view)~~EditAttach~~
---+ Language Change Specification for Signatures Required in Association Lists

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-I03 |
| <sticky><b>Version:</b>   </sticky> | 1 {06-Feb-2017} |
| <sticky><b>Date:</b>      </sticky> | 06-Feb-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting |
| <sticky><b>Author:</b>    </sticky> | Patrick Lehmann |
| <sticky><b>Email:</b>     </sticky> | [[Main.PatrickLehmann]] |
| <sticky><b>Source Doc:</b></sticky> | [[AssociationListSignatures][Signatures Required in Association Lists]] |
| <sticky><b>Summary:</b>   </sticky> | Handle overloaded generic subprograms in generic association lists. |

---+++ Voting Results: Cast your votes here

Yes:
   1 <span data-mce-mark="1">%USERSIG{PatrickLehmann - 2017-02-06}%</span> - ver 1
   1 <span data-mce-mark="1">%USERSIG{MartinZabel - 2017-02-07}%</span> - ver 1
   1 <span data-mce-mark="1">%USERSIG{ThomasPreusser - 2017-02-07}%</span> - ver 1
   1 <span data-mce-mark="1">%USERSIG{JimLewis - 2017-02-21}%</span> - ver 1
   1 %USERSIG{RobGaddi - 2017-03-16}% - ver 1

No:

Abstain:
   1 <span data-mce-mark="1">%USERSIG{BrentHahoe - 2017-02-16}%</span> Version 1 - Abstain due to lack of personal time for review.
   1 <span data-mce-mark="1">%USERSIG{MartinThompson - 2017-02-17}%</span> Version 2 - Abstain due to lack of personal time for review.
   1 %USERSIG{PeterFlake - 2017-03-16}% - ver 1 implementation complexity does not justify benefit

---++ Style Notes

<span data-mce-mark="1"><noautolink></span>

<sticky>
Changes are shown in %RED%red font%ENDCOLOR%.%BR%
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR%
Editing or reviewing notes in %GREEN%green font%ENDCOLOR%.
 
---++ Reviewing Notes
Generic subprograms can be overloaded, but mapping subprograms to such a formal parameter is not possible, because a formal name must be %BR%
unique. This LCS introduces signatures at a formal generic subprogram to allow multiple mappings in a generic map aspect.


---++ Details of Language Change
---+++ 4.5.3 Signatures
A signature distinguishes between overloaded subprograms and overloaded enumeration literals based on their parameter and result type profiles. %BR%
A signature can be used in a subprogram instantiation declaration%RED%, generic map aspect%ENDCOLOR%, attribute name, entity designator, or alias declaration.

%GREEN%[...]%ENDCOLOR%


---+++ 6.5.7.1 General
%GREEN%[...]%ENDCOLOR%
<pre>
formal_designator ::=
    <i>generic</i>_name %RED%[ signature ]%ENDCOLOR%
  | <i>port</i>_name
  | <i>parameter</i>_name
</pre>
%GREEN%[...]%ENDCOLOR%


---+++ 6.5.7.2 Generic map aspects
%GREEN%[...]%ENDCOLOR%

In each case, for a formal generic constant, it is an error if a scalar formal is associated with more than one actual, and it is an error if a scalar subelement %BR%
of any composite formal is associated with more than one scalar subelement of an actual. Similarly, for a formal generic type, a formal generic subprogram, or a %BR%
formal generic package, it is an error if the formal is associated with more than one actual. %RED%Thus, it is an error if two formal generic subprograms have the same %BR%
designator and the same signature. It is also an error if a formal generic subprogram has a signature, which is not listed in an interface subprogram declaration %BR%
for that designator.%ENDCOLOR%

An actual associated with a formal generic constant in a generic map aspect shall be an expression or the reserved word open. An actual associated with a formal %BR%
generic type shall be a subtype indication. An actual associated with a formal generic subprogram shall be a name that denotes a subprogram whose profile conforms %BR%
to that of the formal, or the reserved word open. The actual, if a predefined attribute name that denotes a function, shall be one of the predefined attributes %BR%
'IMAGE, 'VALUE, 'POS, 'VAL, 'SUCC, 'PRED, 'LEFTOF, or 'RIGHTOF.

%GREEN%[...]%ENDCOLOR%


---+++ Annex C

<pre>
formal_designator ::=
    <i>generic</i>_name %RED%[ signature ]%ENDCOLOR%
  | <i>port</i>_name
  | <i>parameter</i>_name
</pre>


---++ Comments




@TODO solicit input from vendors

-- %BUBBLESIG{JimLewis - 2017-03-02}%


*PF:* implementation complexity does not justify benefit

*PL:* what complexity? Signatures to distinguish subprograms are already implemented in the language.

The last revision didn't address this very need, that's why it's an ISAC issue. Other concepts like LCS 059 require this language bugfix.

I know there is a workaround which is more than ugly and adds a lot of complexity to the user code to work around a design fault from 2008.

So please elaborate what complexity do you mean?

-- %BUBBLESIG{PatrickLehmann - 2017-03-09}%


This is completely unnecessary syntax.  No signature is required to unambiguously associate a suprogram with the appropriate (named) formal using the standard subprogram overloading rules. 

The LRM rule is too strict as written (stating that a formal name can only appear once) and can be relaxed to allow the associations without additional syntax.  The formal name limitation should rather be that each (overloaded) formal can only be associated once after overload resolution.

I know this is already approved, but it is worth re-opening this issue since the syntax adds no value.

-- %BUBBLESIG{KarlEisenhofer - 2017-03-24}%
%COMMENT%</sticky>

</noautolink>
Topic revision: r1 - 2017-04-02 - 16:19:24 - TWikiGuest
P1076