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


  1. Jim Lewis - 21-Mar-2017 ver 6
  2. Thomas Preusser - 2017-02-07 - ver 3
  3. Martin Zabel - 2017-02-26 - ver 6
  4. Patrick Lehmann - 2017-03-22 - ver 6



  1. Brent Hayhoe - 2017-02-16 Version 3 - Abstain due to lack of personal time for review.
  2. 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 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


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
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback