Support anonymous types

Currently only named types are supported in type indications, such as the following.

signal a: std_logic_vector(7 downto 0);
-- can't write `array (7 downto 0) of std_logic` instead of std_logic_vector

function e (f: my_record) returns my_2_tuple;
-- can't write `function e (f: my_record) returns record g: string; h: boolean end record;`

This means that all types must be declared ahead of time in some declarative section. And all types, no matter how simple, must be put in a package if the type appears on a public interface. This can be tedious, and while VHDL cares more about being explicit than avoiding tedium, this limitation does not provide useful explicitness.

Additionally, this may be used for supporting multiple returns without having to introduce a special feature. Multiple returns could be an anonymous record type. It may also be useful for dealing with tuples which are often used in other programming languages anonymously.

Proposal

Anonymous types

Anonymous types are types that cannot be named because they are not bound to a name. They will internally have a unique an canonical name not specified by the spec.

Anonymous types can be written by using the existing type definition syntax.

All equivalent uses of an anonymous type refer to the same anonymous type. Meaning the following anonymous array type definitions in different declarative sections refer to the same type and are thus compatible.

signal g: array (0 to 3) of std_logic;

function h(i: array (0 to 3) of std_logic) return record j: integer; k: boolean end record;

Typing rules

All named types with the same anonymous type as the definition will be distinct (but potentially compatible) types from each other, with the anonymous type as the supertype. This means that all types that are just named versions of an anonymous type can be used in expressions and associations expecting the anonymous type being implicitly upcast to the anonymous supertype; much like how values of subtype definitions can be passed to expressions and associations of their supertype.

type integer_array is array <> of integer;

function sum(values: array (0 to 3) of integer) returns integer;

signal l: integer_array(0 to 3);
signal m : integer;

m <= sum(l);  -- This is legal

Grammar

The grammar should be updated so that type definitions can appear wherever type indications are currently accepted. Type definitions (besides enums) tend to start with a keywords: record, access, array, protected, etc. so ambiguity can be avoided (let me know otherwise).

I can provide a proposed change the grammar if there's further interest.