P1076 Web>VHDL2017>LCS2016_049>LCS2016_049_history (2017-07-16, JimLewis)EditAttach

Language Change Specification for Map Generics On Subprogram Call

LCS Number:	LCS-2016-049 History
Version:	7
Date:	21-Mar-2017
Status:	Voting
Author:	Jim Lewis
Email:	Main.JimLewis
Source Doc:	Map Generics On Subprogram Call
Summary:	Map Generics On Subprogram Call

Voting Results: Cast your votes here

Yes:

No:

Abstain:

Brent Hayhoe - 2017-02-16 Version 3 - Abstain due to lack of personal time for review.
Martin Thompson- 2017-02-17 Version 2 - Abstain due to lack of personal time for review.

Revision History

Version 7: 21-Mar-2017

Added edit in 3rd paragraph in 4.2.1 on page 20

Version 6: 10-Mar-2017

Added edit in 5th paragraph in 6.5.7.2 on page 84

Version 5: 25-Feb-2017

Added text on elaboration of uninstantiated subprograms.
- new item c, minor edit to b, current c becomes d

Version 4: 24-Feb-2017

Deleted edit to paragraph with parentheses. Same paragraph is in 10.7. Either edit both or neither. Decided neither.
Replaced - which was displaying as ?

Version 3: 30-Jan-2017

Replaced "generic map ... actual_generic_part" with generic_map_aspect to reuse already defined terms
Added parameter map key words and defined parameter_map_aspect to be consistent with port_map_aspect.
- This was an oversight as I thought 1076-2008 already added parameter map.

Version 2: 21-Jan-2017

Added generic map before actual_generic_part

Version 1: Initial 13-Jan-2017

Reviewing Notes

At first, this does not seem likea worthy item to do, however, it is the required step toward doing anonymous types on interfaces. See LCS_2016_016

Style Notes

Changes are shown in red font. Deletions are ~~crossed out~~. Editing notes in green font.

Relevant sections of the LRM

function calls - expressions procedure calls - sequential statements, concurrent statements Execution and Elaboration

Comments

In a function or procedure call, both the generic association list as well as the parameter association list are optional. How should a parser decide wether f(x => y) is a function call with parameter x set to y, or function call with generic x set to y? There might be 2 functions visible with an appropriate signature for each case.

-- Martin Zabel - 2017-01-20

The parser doesn't have to decide, semantic analysis can disambiguate the expressions. Just like overloading, if the expression is ambiguous it should be rejected by the compiler.

-- Lieven Lemiengre - 2017-01-21

Added generic map to the call. I think it is important that we keep consistent with other parts of the language. If in the future we introduce some form of abbreviation, it would need to apply to all uses and in particular to both subrprogram calls and entity/component instances.

-- Jim Lewis - 2017-01-21

@Jim: Thanks for changing to "generic map".

I also made some fixes which I think are not worse to bump the revision number: Within the grammar rules, I changed the font of "generic" in "generic_association_list" to italics. I also fixed two types.

-- Martin Zabel - 2017-01-23

@MZ thanks for the edits.

-- Jim Lewis - 2017-01-26

Did you forget to change it for procedure calls?

-- Lieven Lemiengre - 2017-01-27

@LL Thanks. It was actually a test to see if you were paying attention. Good catch.

-- Jim Lewis - 2017-01-27

There is some resolvable conflict between concurrent procedure calls & instantiations

lbl : foo -- is it a procedure call or an instantiation

This change makes this problem bigger

lbl : foo generic map(...) -- is it a procedure call or an instantiation

These things can be resolved but they're a real pain to deal with

-- Lieven Lemiengre - 2017-02-07

...but the pain exists since years. It just stronger smile

We can't change the fact that the final decision for procedure call vs. instantiation needs to read a lot of characters/tokens until it can decide what it is.

-- Patrick Lehmann - 2017-02-07

Topic revision: r1 - 2017-07-16 - 16:39:47 - JimLewis

P1076