(r36) LCS2016_059 < P1076

P1076 Web>VHDL2017>LCS2016_059 (revision 36) (raw view)~~EditAttach~~
---+ Language Change Specification for Improved Type Generics
---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-059 |
| <sticky><b>Version:</b>   </sticky> | 10 |
| <sticky><b>Date:</b>      </sticky> | 26-Mar-2017 |
| <sticky><b>Status:</b>    </sticky> | Voting |
| <sticky><b>Author:</b>    </sticky> | Patrick Lehmann %BR% Martin Zabel %BR% Jim Lewis  |
| <sticky><b>Email:</b>     </sticky> | [[Main.PatrickLehmann]] %BR% [[Main.MartinZabel]] %BR% [[Main.JimLewis]] |
| <sticky><b>Source Doc:</b></sticky> | [[ArrayTypeGenerics][Array Type Generics]] |
| <sticky><b>Summary:</b>   </sticky> | Adds type class insurances (discrete, integer, float, array, ...) for generic types. |

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

Yes:
   1 %USERSIG{LievenLemiengre - 2017-02-16}% - ver 5
   1 %USERSIG{DanielKho - 2017-01-19}% - ver 1
   1 %USERSIG{ThomasPreusser - 2017-01-19}% - ver 3 - but consider comment of 2017-02-08
   1 %USERSIG{JimLewis - 22-Mar-2017}% - ver 9
   1 %USERSIG{PatrickLehmann - 26-Mar-2017}% - ver 10

No:
   1 

Abstain:
   1 %USERSIG{BrentHahoe - 2017-02-16}% Version 5 - Abstain due to lack of personal time for review.
   1 %USERSIG{MartinThompson - 2017-02-17}% Version 2 - Abstain due to lack of personal time for review.

---++ Style Notes

<noautolink>

<sticky>
Additions are shown in %RED%red font%ENDCOLOR%.%BR%
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR%
Restructuring is shown in crossed out %GRAY%<del>gray font%ENDCOLOR% somewhere else in %GRAY%gray font%ENDCOLOR%.%BR%
Editing or reviewing notes in %GREEN%green font%ENDCOLOR%.
 
---++ Reviewing Notes
*Version 1:* 19-Jan-2017 %BR%
VHDL's current generic types allow the user to pass an arbitrary type to a subprogram, entity or package, but such a generic type has no 
type class, because the class of the mapped type is only known at elaboration time, whereas the generic type is already needed at analysis 
time. So currently, VHDL can not guarantee, if a generic type is e.g. an array. Without knowledge of the type class, we have no predefined 
operators except for equal/unequal and we have no attributes like ='length= or ='range=.

This LCS adds type class assurances to generic type definitions in the generic list. It extends the list of predefined operators (implicitly 
declared in an interface list) if the type class is known. It also adds predefined attributes form types and objects.

*Version 2:* 20-Jan-2017 %BR%
Definitions regarding attributes defined for interface types and objects thereof have been unified.

*Version 3:* 05-Feb-2017 %BR% 

*Version 4:* 11-Feb-2017 %BR% 
   * Improved paragraphs

*Version 5:* 12-Feb-2017 %BR%
   * Restored lost changes from Version 2

*Version 6:*  10-Mar-2017 %BR%
   * Updated text in 6.5.7.2 Generic map aspects
  
*Version 7:*  19-Mar-2017
   * Introduce type classes
   * Remove named implicit generic types
   * Add syntax for anonymous types to describe implicit types (from LCS 016)
   * Use the private keyword like in Ada

*Version 8:* 21-Mar-2017
   * Renamed typeclass to incomplete type definition
   * Moved operator and attributes to 5.8
   * revised text about unknown types to specify an anonymous type indication

*Version 9:* 22-Mar-2017
   * Minor grammar and edits
	 
*Version 10:* 26-Mar-2017
   * Concatenation is only for single dimensional arrays
   * Added aggregation as a basic operation

---++ Details of Language Change
---+++ 5.1 General

---++++ On page 35 Edit 4th paragraph as below 
There are five %RED%primary%ENDCOLOR% classes of types. 
Scalar types are integer types, 
floating-point types, physical types, and types
defined by an enumeration of their values; values of these types have no elements. 
Composite types are array and record types; 
values of these types consist of element values. 
Access types provide access to objects of a
given type. 
File types provide access to objects that contain a 
sequence of values of a given type. 
Protected types provide atomic and exclusive access 
to variables accessible to multiple processes.

---++++ On page 35 add new paragraph after 4th paragraph (above)
%RED%For ports, parameters, and external names the type of an object 
may also be specified as an anonymous type.
An anonymous type is an incomplete type indication that defines
a set of allowed operations.%ENDCOLOR%


---+++ 5.5.1 General
A file type definition defines a file type. File types are used to define objects representing files in the host system environment. The value of 
a file object is the sequence of values contained in the host system file.

<pre>
file_type_definition ::= <b>file of</b> type_mark
</pre>

The type mark in a file type definition defines the subtype of the values contained in the file. The type mark may denote either a fully constrained, 
a partially constrained, or an unconstrained subtype. The base type of this subtype shall not be a file type, an access type, %RED%or%ENDCOLOR% a protected type 
%RED%<del>, or a formal generic type</del>%ENDCOLOR%. If the base type is a composite type, it shall not contain a subelement of an access type. If the base 
type is an array type, it shall be a one-dimensional array type whose element subtype is fully constrained. If the base type is a record type, it shall be 
fully constrained.

%RED%NOTE -- A type mark in a file type declaration may be a formal generic type or have a subelement of a formal generic type. However, for an instance 
of the enclosing declaration that defines the formal generic type, a check is required that the actual generic type is neither an access type, protected 
type or file type nor contains a subelement of an access type, protected type or file type. Depending on the implementation, this check may be done 
during analysis of the instantiation, or it may be deferred until the design hierarchy is elaborated.%ENDCOLOR%

---+++ 5.8 Anonymous Types %GREEN%[new]%ENDCOLOR%
---+++ 5.8.1 General %GREEN%[new]%ENDCOLOR%
%RED%An anonymous type is an incomplete type indication that defines
a set of allowed operations.
An anonymous type is a superset of type classes.%ENDCOLOR%

%RED%An anonymous type can be classified as a private, scalar, discrete,
integer, physical, floating, array, access, or file incomplete
type definition.%ENDCOLOR%

<pre>%RED%
%RED%anonymous_type_indication ::=             %GREEN%[Moved from LCS 016]%ENDCOLOR%
  <b>type is</b> incomplete_type_definition%ENDCOLOR%

incomplete_type_definition ::=
    private_incomplete_type_definition
  | scalar_incomplete_type_definition
  | discrete_incomplete_type_definition
  | integer_incomplete_type_definition
  | physical_incomplete_type_definition
  | floating_incomplete_type_definition
  | array_incomplete_type_definition
  | access_incomplete_type_definition
  | file_incomplete_type_definition

incomplete_subtype_indication ::=
    subtype_indication
  | anonymous_type_indication

incomplete_type_mark ::=
    type_mark
  | anonymous_type_indication

private_incomplete_type_definition ::= <b>private</b>

scalar_incomplete_type_definition ::= <b><></b>

discrete_incomplete_type_definition ::= <b>( <> )</b>

integer_incomplete_type_definition ::= <b>range <></b>

physical_incomplete_type_definition ::= <b>units <></b>

floating_incomplete_type_definition ::= <b>range <> . <></b>

array_incomplete_type_definition ::=
  <b>array (</b> array_index_incomplete_type_list <b>)</b>
    <b>of</b> <i>element</i>_incomplete_subtype_indication
 
array_index_incomplete_type_list ::= 
    array_index_incomplete_type { <b>,</b> array_index_incomplete_type } 

array_index_incomplete_type ::=
    index_subtype_definition
  | index_constraint
  | anonymous_type_indication

access_incomplete_type_definition ::=
  <b>access</b> <i>access</i>_incomplete_subtype_indication

file_incomplete_type_definition ::=
  <b>file of</b> <i>file</i>_incomplete_type_mark
%ENDCOLOR%</pre>

%RED%The following basic operations are defined for all 
incomplete type definitions: assignment, allocation, type qualification 
and type conversion.  
In addition, each incomplete type definition may include additional 
predefined operators and attributes. %ENDCOLOR%

---+++ 5.8.2 Private incomplete type %GREEN%[new]%ENDCOLOR%
%RED%A private incomplete type is an anonymous type that denotes any type 
except file and protected types.%ENDCOLOR%

%RED%The following operators are implicitly defined for a private incomplete type: %GRAY%equality (!=) and inequality (/=)%ENDCOLOR%. The predefined attributes for 
a private incomplete type, and objects thereof, are the same as the predefined attributes common to all types other than a file type or 
protected type, and objects thereof, respectively, as listed in section 16.2.%ENDCOLOR%


---+++ 5.8.3 Scalar incomplete type %GREEN%[new]%ENDCOLOR%
%RED%A scalar incomplete type is an incomplete type definition that denotes any scalar type.%ENDCOLOR%

%RED%The following operators are implicitly defined for a scalar incomplete type: %GRAY%equality (!=), inequality (/=)%ENDCOLOR%, less than (<), less than or equal (<=), greater than (>), 
greater than or equal (>=), MINIMUM, MAXIMUM, and TO_STRING. The predefined attributes for the scalar incomplete type, and objects thereof are 
the same as the predefined attributes for scalar types, and objects thereof, respectively, as listed in section 16.2.%ENDCOLOR%


---+++ 5.8.4 Discrete incomplete type  %GREEN%[new]%ENDCOLOR%
%RED%A discrete incomplete type is an anonymous type that denotes any discrete type.%ENDCOLOR%

%RED%The following operators are implicitly defined for a discrete incomplete type: 
%GRAY%equality (!=), inequality (/=)%ENDCOLOR%, less than (<), less than or equal (<=), greater than (>), 
greater than or equal (>=), MINIMUM, MAXIMUM, and TO_STRING. The predefined attributes for the discrete incomplete type, and objects thereof are 
the same as the predefined attributes for discrete types, and objects thereof, respectively, as listed in section 16.2.%ENDCOLOR%

---+++ 5.8.5 Integer incomplete type %GREEN%[new]%ENDCOLOR%
%RED%An integer incomplete type is an anonymous type that denotes any integer type.%ENDCOLOR%

%RED%The following operators are implicitly defined for an integer incomplete type: 
%GRAY%equality (!=), inequality (/=)%ENDCOLOR%, less than (<), 
less than or equal (<=), greater than (>), 
greater than or equal (>=), positive (+), negation (-), plus (+), minus (-), 
multiply (!*), divide (/), power (!**), remainder (rem), modulo (mod), absolute (abs), 
MINIMUM, MAXIMUM, and TO_STRING. The predefined attributes for the 
integer incomplete type, and objects thereof are the same as the predefined 
attributes for integer types, and objects thereof, respectively, 
as listed in section 16.2.%ENDCOLOR%

---+++ 5.8.6  Physical incomplete type %GREEN%[new]%ENDCOLOR%
%RED%A physical incomplete type is an anonymous type that denotes any physical type.%ENDCOLOR%

%RED%The following operators are implicitly defined for a physical incomplete type: 
%GRAY%equality (!=), inequality (/=)%ENDCOLOR%, less than (<), less than or equal (<=), greater than (>), 
greater than or equal (>=), positive (+), negation (-), plus (+), minus (-), multiply (!*), divide (/), remainder (rem), modulo (mod), absolute (abs), 
MINIMUM, MAXIMUM, and TO_STRING. The predefined attributes for the physical incomplete type, and objects thereof are the same as the predefined 
attributes for physical types, and objects thereof, respectively, as listed in section 16.2.%ENDCOLOR%


---+++ 5.8.7 Floating incomplete type %GREEN%[new]%ENDCOLOR%
%RED%A floating incomplete type is an anonymous type that denotes any floating-point type.%ENDCOLOR%

%RED%The following operators are implicitly defined for a floating incomplete type: 
%GRAY%equality (!=), inequality (/=)%ENDCOLOR%, less than (<), 
less than or equal (<=), greater than (>), 
greater than or equal (>=), positive (+), negation (-), plus (+), minus (-), 
multiply (!*), divide (/), power (!**), absolute (abs), 
MINIMUM, MAXIMUM, and TO_STRING. 
The predefined attributes for the floating incomplete type, 
and objects thereof are the same as the predefined 
attributes for floating-point types, and objects thereof, 
respectively, as listed in section 16.2.%ENDCOLOR%


---+++ 5.8.8 Array incomplete type %GREEN%[new]%ENDCOLOR%
%RED%An array incomplete type is an anonymous type 
that denotes any array type.%ENDCOLOR%

%RED%The array index incomplete type list may consist of 
an index subtype definition, an index constraint, or 
an anonymous type indication.
For an array incomplete type that has more than one dimension,
it is an error if the array index incomplete type list has 
both an index subtype definition and an index constraint.
%ENDCOLOR%

%RED%The element incomplete subtype indication may either be 
a subtype indication or an anonymous type indication.
%ENDCOLOR%

%RED%The basic operation aggregation is defined for any array incomplete type.
The following operators are implicitly defined for any array incomplete type: 
%GRAY%equality (!=), and inequality (/=)%ENDCOLOR%. In addition, the operator
concatenation (&) is implicitly defined, if the array incomplete type denotes
a single dimensional array. If the array incomplete type denotes 
a scalar array type, then the following operators are defined: 
less than (<), less than or equal (<=), greater than (>), 
greater than or equal (>=), MINIMUM and MAXIMUM. 
The predefined attributes for the array incomplete type, 
and objects thereof, are the same as the predefined attributes for array types, 
and objects thereof, respectively, as listed in section 16.2. 
Objects created from array incomplete type can be used as a prefix 
in indexed names (see 8.4) and slice names (see 8.5).%ENDCOLOR%


---+++ 5.8.9 Access incomplete type %GREEN%[new]%ENDCOLOR%
%RED%An access incomplete type is an anonymous type 
that denotes any access type.%ENDCOLOR%

%RED%The access incomplete subtype indication may either be 
a subtype indication or an anonymous type indication.
%ENDCOLOR%

%RED%The following operators are implicitly defined for an access incomplete type: 
%GRAY%equality (!=), inequality (/=)%ENDCOLOR%, and DEALLOCATE. The predefined attributes for the 
interface access type, and objects thereof are the same as the predefined attributes for access types, and objects thereof, respectively, as listed in 
section 16.2.%ENDCOLOR%

%GREEN%[If LCS-2016-030 (Garbage Collection) is approved, the operation DEALLOCATE is not listed as the previous section.]%ENDCOLOR%


---+++ 5.8.10 File incomplete type %GREEN%[new]%ENDCOLOR%
%RED%A file incomplete type is an anonymous type 
that denotes any file type.%ENDCOLOR%

%RED%The file incomplete type mark may either be 
a type mark or an anonymous type indication.
%ENDCOLOR%

%RED%The following operators are implicitly defined for a file incomplete type: 
FILE_OPEN, FILE_CLOSE, READ, WRITE, FLUSH and ENDFILE. 
The predefined attributes for the file incomplete type, and objects thereof are the same as the predefined attributes for file types, and objects thereof, respectively, as listed in section 16.2.%ENDCOLOR%

%GREEN%[Editor note: If LCS-2016-006a is approved, then the new file operations from the list of predefined operators needs to be extended.]%ENDCOLOR% %BR%
%GREEN%[Editor note: FILE_REWIND, FILE_SEEK, FILE_TRUNCATE, FILE_STATE, FILE_MODE, FILE_POSITION, FILE_SIZE, FILE_CANSEEK]%ENDCOLOR%


---+++ 6.5.1 General %GREEN%[For reviewers to follow the chain of EBNF rules.]%ENDCOLOR%
An interface declaration is an interface object declaration, an interface type declaration, 
an interface subprogram declaration, or an interface package declaration.

<pre>
interface_declaration ::=
      interface_object_declaration
    | interface_type_declaration
    | interface_subprogram_declaration
    | interface_package_declaration
</pre>


---+++ 6.5.3 Interface type declarations
---+++ 6.5.3.1 General %GREEN%[NEW; new level]%ENDCOLOR%
An interface type declaration declares an interface type that appears as a formal generic of a generic clause.

%GREEN%[For reviewers to follow the chain of EBNF rules.]%ENDCOLOR%
<pre>
interface_type_declaration ::=
%RED%<del>  interface_incomplete_type_declaration</del>
    %GRAY%<b>type</b> identifier%ENDCOLOR% <b>[ is incomplete_type_definition ]</b>

<del>interface_incomplete_type_declaration ::=</del>%ENDCOLOR%
    %GRAY%<del><b>type</b> identifier</del>%ENDCOLOR%
</pre>

An interface type provides a means for the environment to determine a type to be used for objects in a particular portion of a description. 
The set of values and applicable operations for an interface type may be determined by an associated subtype in the environment. 
The manner in which such associations are made is described in 6.5.7. 
%RED%A generic type declared by an interface type declaration without an 
incomplete type definition is called an <i>unclassified generic type</i>, otherwise it is called a <i>classified generic type</i>. 
An unclassified type denotes a private incomplete type.
A classified generic type is any interface type declaration except a private incomplete type.
%ENDCOLOR%

%RED%<del>Within an entity declaration, an architecture body, a component declaration, or an uninstantiated subprogram or package declaration that 
declares a given interface type, </del>%GRAY%<del>the type declared by the given interface type declaration is distinct from the types declared by other interface 
type declarations and from explicitly declared types</del>%ENDCOLOR%<del>. The name of the given interface type denotes both an undefined base type and a subtype 
of the base type. The class (see 5.1) of the base type is not defined. The following operations are defined for the interface type:</del>%ENDCOLOR%
   * %RED%<del>The </del>%ENDCOLOR%%GRAY%<del>basic operations of assignment, allocation, type qualification and type conversion</del>%ENDCOLOR%
   * %RED%<del>The predefined </del>%GRAY%<del>equality (!=) and inequality (/=)</del>%ENDCOLOR%<del> operators, </del>%GRAY%<del>implicitly declared as formal generic subprograms immediately following the 
     interface type declaration in the enclosing interface list%ENDCOLOR%.</del>%ENDCOLOR%

%RED%<del>The name of an interface type declaration of a block statement (including an implied block statement representing a component instance or a 
bound design entity), a generic-mapped package or a generic mapped subprogram denotes the subtype specified as the corresponding actual in a generic association list.</del>%ENDCOLOR%

%RED%%GRAY%The type declared by a given interface type declaration is distinct from the types declared by other interface type declarations and from types 
explicitly declared%ENDCOLOR% within the construct. 
The following %GRAY%basic operations%ENDCOLOR% are defined for all interface types: %GRAY%assignment, allocation, type qualification 
and type conversion%ENDCOLOR%. 
%RED%Each interface type definition includes the additional predefined operators and attributes 
that are defined for corresponding incomplete type definition (see 5.8).
These additional operators are %GRAY%implicitly declared as formal generic subprograms%ENDCOLOR%
with an interface subprogram default in form of a box (<>)
%GRAY%immediately following the interface type declaration in the enclosing interface list%ENDCOLOR%.%ENDCOLOR%

%RED%Within a construct that has an interface type declaration, 
but does not map it, the name of the given interface type 
denotes both an undefined base type and a subtype of the base type. 
Within a construct that maps a given interface type declaration, 
the name of the given interface type declaration denotes the 
subtype specified as the corresponding actual in a generic 
association list.%ENDCOLOR%


---+++ 6.5.3.2 Array interface type declarations %GREEN%[new]%ENDCOLOR%
%RED%A formal array type and the associated actual array type must 
both be constrained or both be unconstrained. 
Both must have the same dimensionality, 
the same index types in each dimension, 
and the same element types. 
For a formal constrained array type, the index constraint must be 
specified in the form of a type mark, and 
the actual array type must 
have the same index range as the formal array type.%ENDCOLOR%

%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P1 is
  generic (
    type element_type is private;                         -- any type
    type index_type is (<>);                              -- a discrete type
    type array_type is array(index_type) of element_type  -- an array type
  );
end package;

entity E is
end entity;

architecture A of E is
  package I1 is new P1
    generic map (
      element_type => bit,
      index_type =>   natural,
      array_type =>   bit_vector
    );
begin
end architecture;
%ENDCOLOR%</pre>

%RED%If the array index incomplete type is specified
with an anonymous type indication, then 
an implicit formal anonymous type with the same incomplete type defintion 
is declared immediately before the array interface type declaration.
If the element incomplete subtype indication is specified
with an anonymous type indication, then 
an implicit formal anonymous type with the same incomplete type defintion 
is declared immediately before the array interface type declaration.%ENDCOLOR%

%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P2 is
  generic (
    -- type anonymous is (<>);              -- implicitly declared anonymous generic discrete type
    -- type anonymous is private;           -- implicitly declared anonymous unclassified generic type
    type array_type is array(type is (<>)) of type is private
  );
  -- example usage of type aliases to create shorter names
  alias index_type   is array_type'INDEX;    -- alias the implicit type with a name
  alias element_type is array_type'ELEMENT;  -- alias the implicit type with a name
end package;

architecture A of E is
  package I2 is new P2
    generic map (
      -- anonymous => bit_vector'INDEX,   -- implicitly associated; see 6.5.7.2
      -- anonymous => bit_vector'ELEMENT, -- implicitly associated; see 6.5.7.2
      array_type =>   bit_vector
    );
begin
end architecture;
%ENDCOLOR%</pre>


---+++ 6.5.3.3  Access interface type declarations %GREEN%[new]%ENDCOLOR%
%RED%A formal access type and the associated actual access type must 
both have the same designated type.%ENDCOLOR%

%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P1 is
  generic (
    type designated_subtype;                       -- any type
    type access_type is access designated_subtype  -- an access type
  );
end package;

entity E is
end entity;

architecture A of E is
  package I1 is new P1
    generic map (
      designated_subtype => string,
      access_type        => line
    );
begin
end architecture;
%ENDCOLOR%</pre>
%RED%If the access incomplete subtype indication is specified
with an anonymous type indication, then 
an implicit formal anonymous type with the same incomplete type defintion 
is declared immediately before the array interface type declaration.
%ENDCOLOR%

%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P2 is
  generic (
    -- type anonymous is private;                    -- implicitly declared unclassified generic type
    type access_type is access type is private
  );
  -- example usage of type aliases to create shorter names
  alias designated_subtype is access_type'DESIGNATED_SUBTYPE;  -- alias the implicit type with a name
end package;

architecture A of E is
  package I2 is new P2
    generic map (
      -- anonymous => line'DESIGNATED_SUBTYPE, -- implicitly associated; see 6.5.7.2
      access_type => line
    );
begin
end architecture;
%ENDCOLOR%</pre>


---+++ 6.5.3.4  File interface type declarations %GREEN%[new]%ENDCOLOR%
%RED%A formal file type and the associated actual file type must both have the same designated type.%ENDCOLOR%


%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P1 is
  generic (
    type designated_subtype;                      -- any type
    type file_type is file of designated_subtype  -- an file type
  );
end package;

entity E is
end entity;

architecture A of E is
  package I1 is new P1
    generic map (
      designated_subtype => string,
      file_type          =>  line
    );
begin
end architecture;
%ENDCOLOR%</pre>

%RED%If the file incomplete type mark is specified
with an anonymous type indication, then 
an implicit formal anonymous type with the same incomplete type defintion 
is declared immediately before the array interface type declaration.
%ENDCOLOR%

%RED%<b>Example:</b>%ENDCOLOR%<pre>%RED%
package P2 is
  generic (
    -- type anonymous is private;                    -- implicitly declared unclassified generic type
    type file_type is file of type is private
  );
  -- example usage of type aliases to create shorter names
  alias designated_subtype is file_type'DESIGNATED_SUBTYPE;  -- alias the implicit type with a name
end package;

architecture A of E is
  package I2 is new P2
    generic map (
      -- anonymous => line'DESIGNATED_SUBTYPE, -- implicitly associated; see 6.5.7.2
      file_type => line
    );
begin
end architecture;
%ENDCOLOR%</pre>

%RED%NOTE -- A type mark in a file interface type declaration may be a formal generic type or have a subelement of a formal generic type. However, for an instance 
of the enclosing declaration that defines the formal generic type, a check is required that the actual generic type is neither an access type, protected 
type or file type nor contains a subelement of an access type, protected type or file type. Depending on the implementation, this check may be done 
during analysis of the instantiation, or it may be deferred until the design hierarchy is elaborated.%ENDCOLOR%


---+++ 6.5.7.2 Generic map aspects
%GREEN%[Editor note: Paragraph 7]%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 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 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 'IMAGE, 'VALUE, 'POS, 'VAL, 'SUCC, 'PRED, 'LEFTOF, or 'RIGHTOF.

%RED%For a formal generic array interface type declaration, if the array index subtype is represented by
an implicit formal generic type, then an implicit association element is added that associates
the implicit formal with the subtype returned when 'INDEX is applied to the actual of
the corresponding array type association element.%ENDCOLOR%

%RED%For a formal generic array interface type declaration, if the element subtype is represented by
an implicit formal generic type, then an implicit association element is added that
associates the implicit formal with the subtype returned when 'ELEMENT is
applied to the actual of the corresponding array type association element.%ENDCOLOR%

%RED%For a formal generic access interface type declaration, if the designated subtype is represented by
an implicit formal generic type, then an implicit association element is added that associates
the implicit formal with the subtype returned when 'DESIGNATED_SUBTYPE is applied
to the actual of the corresponding access type association element.%ENDCOLOR%

%RED%For a formal generic file interface type declaration, if the designated subtype is represented by
an implicit formal generic type, then an implicit association element is added that associates
the implicit formal with the subtype returned when 'DESIGNATED_SUBTYPE is applied
to the actual of the corresponding file type association element. %ENDCOLOR%

An actual associated with a formal generic package in a generic map aspect shall be a name that denotes an instance of the uninstantiated package named 
in the formal generic package declaration, as follows:

%GREEN%[...]%ENDCOLOR%


---+++ Section 14.3.3.1 General
%GREEN%[Removed operator names. Instead hint to section 6.5.3 for the list of operators.]%ENDCOLOR%

Elaboration of a generic map aspect consists of elaborating the generic association list. The generic
association list contains an implicit association element for each generic constant that is not explicitly
associated with an actual or that is associated with the reserved word open; the actual part of such an
implicit association element is the default expression appearing in the declaration of that generic constant.
Similarly, the generic association list contains an implicit association element for each generic subprogram
that is not explicitly associated with an actual or that is associated with the reserved word open; the actual
part of such an implicit association element is determined by the interface subprogram default as described
in 6.5.6.2. %RED%<del>The generic association list also contains implicit association elements for
the predefined equality (!=) operator and inequality (/=)
operators of each generic type %RED%(see 6.5.3); 
the actual part of such an implicit association element is the name of the
predefined equality operator or inequality operator for the base type of the subtype
indication in the actual part of the association element corresponding to the generic type.</del>%ENDCOLOR%


---+++ Annex C - Syntax Summary
<pre>
%RED%anonymous_type_indication ::=             %GREEN%[Moved from LCS 016]%ENDCOLOR%
  <b>type is</b> incomplete_type_definition

incomplete_type_definition ::=
    private_incomplete_type_definition
  | scalar_incomplete_type_definition
  | discrete_incomplete_type_definition
  | integer_incomplete_type_definition
  | physical_incomplete_type_definition
  | floating_incomplete_type_definition
  | array_incomplete_type_definition
  | access_incomplete_type_definition
  | file_incomplete_type_definition

incomplete_subtype_indication ::=
    subtype_indication
  | anonymous_type_indication

incomplete_type_mark ::=
    type_mark
  | anonymous_type_indication

private_incomplete_type_definition ::= <b>private</b>

scalar_incomplete_type_definition ::= <b><></b>

discrete_incomplete_type_definition ::= <b>( <> )</b>

integer_incomplete_type_definition ::= <b>range <></b>

physical_incomplete_type_definition ::= <b>units <></b>

floating_incomplete_type_definition ::= <b>range <> . <></b>

array_incomplete_type_definition ::=
  <b>array (</b> array_index_incomplete_type_list <b>)</b>
    <b>of</b> <i>element</i>_incomplete_subtype_indication
 
array_index_incomplete_type_list ::= 
    array_index_incomplete_type { <b>,</b> array_index_incomplete_type } 

array_index_incomplete_type ::=
    index_subtype_definition
  | index_constraint
  | anonymous_type_indication

access_incomplete_type_definition ::=
  <b>access</b> <i>access</i>_incomplete_subtype_indication

file_incomplete_type_definition ::=
  <b>file of</b> <i>file</i>_incomplete_type_mark%ENDCOLOR%
  
interface_type_declaration ::=
%RED%<del>  interface_incomplete_type_declaration</del>
    %GRAY%<b>type</b> identifier%ENDCOLOR% <b>[ is incomplete_type_definition ]</b>

<del>interface_incomplete_type_declaration ::=</del>%ENDCOLOR%
    %GRAY%<del><b>type</b> identifier</del>%ENDCOLOR%
%ENDCOLOR%</pre>


---++ Comments
---+++ Version 1
Scalar needs to include any pre-defined operation that is defined for scalars. Currently you are missing =to_string=.
Likewise for anything else that has to_string implemented, it should be indicated as supported.

Why break out physical and floating separately? Why not have a numeric that includes integer, physical, and floating
point types? This way if later we introduce fixed point types (like ADA), that too could be supported.

Rather than using syntax for integer, I was wondering if it would work to allow use of universal_integer? Likewise for
floating point.

-- %BUBBLESIG{JimLewis - 2017-01-21}%


Any thoughts about allowing composition of type classes? I have been thinking about =printf=. Is there a way we would
designate that a type allows any type that supports to_string?

-- %BUBBLESIG{JimLewis - 2017-01-21}%


*JL:* Currently you are missing to_string.

*PL: * Is =to_string= defined per type class (haven't found it there.) OR per type. Operations per type can not implicitly
be visible, because VHDL has no interfaces. If =to_string= is defined for each type individually, it should be considered
to be defined per type class to it can be visible for generic interface types too.

*JL:* Why break out physical and floating separately? Why not have a numeric that includes integer, physical, and floating
point types?

*PL:* The predefined operations on integer, physical and floating are not the same. Restricting all types to numeric would
mean to select the least common set of operations.

*JL:* Rather than using syntax for integer, I was wondering if it would work to allow use of universal_integer.

*PL:* The syntax =range <>= denotes every integer value, thus _universal_integer_ . It's a type class and does not restrict
values to be in range of INTEGER.

*JL:* Is there a way we would designate that a type allows any type that supports to_string?

*PL:* VHDL and Ada have no guarantees that a type supports certain operations, because operations are not part of a type like
in other OO languages. From my point, this is a short coming of both languages and can't be changed. It neither supports
interfaces. If VHDL gets interfaces, we can consider such ideas. Moreover, I think it requires types as first class objects.

Example for a type declaration plus operator.
<pre>
Public Class Train
  Public Property Length as Int32

  Public Sub New(length as Int32)
    me.Length = length
  End Sub

  Operator +(ByVal left As Train, ByVal right As Train)
    Return new Train(left.Length + right.Length)
  End Operator
End Class
</pre>

-- %BUBBLESIG{PatrickLehmann - 2017-01-21}%


I am not real thrilled with the notation. Trying to remember &#60;&#62; is scalar. (&#60;&#62;) is discrete. range &#60;&#62; - integer.
This does not promote the readability that is prevalent in the rest of the language. Note that  for subprograms the notation &#60;&#62;
designates a default mapping that uses a subprogram of the same name. It is also used in interface package declarations.

OTOH, what do we do? I don't have a great answer to this. Perhaps abstract packages. Then pre-define packages for each of these. However,
we don't have a proposal for abstract packages.   

Back to composition, how do I say I want a numeric operation that is permitted to be integer or real?
Can we get more commonality between operators supported for integer, physical, and real
if we were to move some of the functions from ieee.math_real to std.standard?   
VHDL-2008 did some clever things with ieee.std_logic_textio to keep the language changes 
from breaking it (especially a reference of the form ieee.std_logic_textio.hwrite).   
Similar things could be done for ieee.math_real.

-- %BUBBLESIG{JimLewis - 2017-01-24}%


The syntax =(<>)= is also used by Ada. It is like the definition of the matching type. Here are the equivalences:

<pre>
-- any type (as currently used)
type T;

-- scalar types (enum, integer, floating, physical)
type T is <>; -- scalar type

-- discrete types (enum, integer)
type enum %RED%is (%ENDCOLOR%e1, e2%RED%)%ENDCOLOR%;
type T %RED%is ( <> )%ENDCOLOR%

-- integer types
type int %RED%is range 0%ENDCOLOR% to 7;
type T %RED%is range <>%ENDCOLOR%
-- also used in "array(natural %RED%range <>%ENDCOLOR%)"

-- floating types
type float %RED%is range 0.0%ENDCOLOR% to 1.0;
type T %RED%is range <>.<>%ENDCOLOR%

-- physical types
type mem %RED%is units%ENDCOLOR%
  byte;
  kbyte = 1014 byte;
end units
type T %RED%is units <>%ENDCOLOR%;

-- array types
type arr %RED%is array(%ENDCOLOR%integer range <>%RED%) of%ENDCOLOR% bit;
type T %RED%is array(%ENDCOLOR%integer range <>%RED%) of%ENDCOLOR% bit;

-- access types
type acc %RED%is access%ENDCOLOR% string;
type T %RED%is access%ENDCOLOR% string;

-- file types
type f %RED%is file of%ENDCOLOR% string;
type T %RED%is file of%ENDCOLOR% string;
</pre>

Even with abstract package, there will be no numeric type. A user needs to use a scalar type and pass in the operators by hand.

-- %BUBBLESIG{PatrickLehmann - 2017-01-25}%
---+++ Version 3

Fixed some typos - some of them very often due to the copy-and-paste of errors. Is there any way we can avoid all this repetition
in 6.5.3.x? Also, the references to _normal_ xyz types are very informal. Could we maybe avoid the re-iteration of the implicit
standard operations inherited from these types altogether? In the end, all this copying and re-stating is only an opportunity
for maintenance hazards.

-- %BUBBLESIG{ThomasPreusser - 2017-02-08}%


What if a generic type T declaration is used in an array interface type declarations and in an access interface type declarations,
and the formal is not associated in a generic map aspect. Then clause 6.5.7.2 is ambiguous, whether the generic type T is
automatically determined:
   * from ='ELEMENT= applied to the actual of the corresponding array type association element, or
   * from ='DESIGNATED_SUBTYPE= applied to the actual of the corresponding access type association element.

*I propose the following solution:* remove all the new paragraphs for clause 6.5.7.2 *and* update all examples.

If this solution is accepted by Patrick or further reviewers, I will edit it in.

-- %BUBBLESIG{MartinZabel - 2017-02-10}%


Can you give an example? I don't see it.

You can't remove 6.5.7.2! Without it the whole LCS gets a big problem...

-- %BUBBLESIG{PatrickLehmann - 2017-02-10}%

@PL: Here is the example, I have mentioned above:

<verbatim>
package P1 is
  generic (
    type element_type;                                    -- any type
    type index_type is (<>);                              -- a discrete type
    type array_type is array(index_type) of element_type  -- an array type
    type access_type is access element_type               -- an access type
  );
end package;

entity E is
end entity;

architecture A of E is
  package I1 is new P1
    generic map (
      array_type => bit_vector,
      file_type  => line
    );
begin
end architecture;
</verbatim>

Then, according to the rules of clause 6.5.7.2, =index_type= is implicitly associated with =bit_vector'INDEX=. That works as expected.

But, =element_type= can be either implicitly associated with:
   * =bit_vector'ELEMENT= because the "unassociated formal is a generic type and this formal is the element subtype indication of an array type definition", or
   * =line'DESIGNATED_SUBTYPE= because the " unassociated formal is a generic type and this formal is the designated subtype of an access type definition".

Thus, the additions to clause 6.5.7.2 are ambiguous. Of course, the example is not valid. A check is required, that if a generic type is used within other generic types, then the former generic type must be always associated.

I see no problem in removing the additions to clause 6.5.7.2. These are only syntatic sugar. The package instantiation can still be:

<verbatim>
entity E is
end entity;

architecture A of E is
  package I1 is new P1
    generic map (
      element_type => bit,
      index_type => natural,
      array_type => bit_vector,
      file_type  => line         -- an error will be reported here.
    );
begin
end architecture;
</verbatim>

-- %BUBBLESIG{MartinZabel - 2017-02-11}%
---+++ Version 5



@MZ:  For an formal generic array type, whose index type and element type are not defined, the name of these types are 
part of the declaration.   Hence, either of the following are ok:
<pre>    type array_type is array(index_type) of element_type ;
    type FlintStoneArrayType is array (FredIndexType) of WilmaElementType ; </pre>

Hence, if on were to write:
<pre>    type array_type is array(index_type) of element_type ;
    type access_type is access element_type ;</pre>

And during association, if element_type is not of the same subtype for both, then one would expect an error.
We probably do need to specify that this is an error somewhere.   



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


@Jim: Are you talking about my issue reported on 2017-02-10? This was already fixed with version 4 / 5 of this LCS.

-- %BUBBLESIG{MartinZabel - 2017-03-10}%


The syntax &#60;&#62;, (&#60;&#62;), range &#60;&#62;, units &#60;&#62; and range &#60;&#62;.&#60;&#62; is not human friendly, so, please consider the following:
<verbatim>
type typ1 is scalar  ;
type typ2 is discrete;
type typ3 is integer ;
type typ4 is physical;
type typ5 is real    ; -- or floating
</verbatim>
Where the identifiers scalar, discrete, integer, physical and real (or floating) would be new keywords, but not reserved words, so the language will be fully backwards compatible.

This is not new to VHDL, an identifier can already have dual behaviour as keyword and identifier as is the case for range in a range_constraint or in a range_attribute_name.

I am not sure of the usefulness of classifying scalar types, in which case would suggest not adding the feature. Can a real world use case be provided for it?


-- %BUBBLESIG{VicenteBergas - 2017-03-11}%


*VB:* Where the identifiers scalar, discrete, integer, physical and real (or floating) would be new keywords, but not reserved words, so the language
will be fully backwards compatible.%BR%
*PL:* This syntax is not possible. It would require that integer and real become reserved words (keywords), but they are already used as types.

VHDL has no concept of context sensitive reserved words and does strictly distinguish between a lexer and a parser. This means, all &#34;keywords&#34;
must be reserved words for the lexer. This would also complicate the already very complex grammar and parser infrastructure.

*VB:* The syntax &#60;&#62;, (&#60;&#62;), range &#60;&#62;, units &#60;&#62; and range &#60;&#62;.&#60;&#62; is not human friendly%BR%
*PL:* Please see my comment from 25.01.2017. It shows the similarity of the used syntax and how types are currently declared. Moreover this syntax is
the same as used by Ada (VHDL is derived from Ada) and is in sync with the proposed VHDL extension called SUAVE.

*VB:* This is not new to VHDL, an identifier can already have dual behaviour as keyword and identifier as is the case for range in a range_constraint or in
a range_attribute_name%BR%
*PL:* This is possible, because attribute names are handled with an exception. You can call them secondary or context dependent keywords.

*VB:* I am not sure of the usefulness of classifying scalar types, in which case would suggest not adding the feature. %BR%
*PL:* All type classes and all type sub-classes of scalar are covered by this LCS. It's:
   1 A question of orthogonality and
   2 the only possibility to get ordering operations for a type without specifying a more exact type class.

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


In 5.2.1, the production for file_incomplete_type_definition appears to be mangled:
<pre>file_incomplete_type_definition ::= file_type_definition
  file of type_mark_or_incomplete_type_definition</pre>

It should be one of the following:
<pre>file_incomplete_type_definition ::=  file of type_mark_or_incomplete_type_definition</pre>
or
<pre>file_incomplete_type_definition ::=  file_type_definition</pre>

Then in the examples in  6.5.3.10 Interface file type declarations the &#34;of&#34; is missing in some (all?) of the examples:
<pre>package P1 is
  generic (
    type designated_subtype;                   -- any type
    type file_type is file designated_subtype  -- an file type
  );</pre>

It should be the following right?
<pre>    type file_type is file designated_subtype  -- an file type</pre>

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

---+++ Version 10

%COMMENT%
</sticky>
</noautolink>
Topic revision: r1 - 2017-04-02 - 15:47:54 - TWikiGuest
P1076