(no subject)

!number LCS-0008(2)
!title Improved aliasing and import/export
!requirements-addressed-herein VHDL92-DR-10
!requirements-addressed-herein VHDL92-DR-37 (partial)
!IR-reference IR-0026
!IR-reference IR-0043
!history-log
(1) Aug 9, 1991 -- Initial version
(2) Feb 6, 1992 -- Changed syntax of parameter-result profile; added new
       discussion for recent issues

!brief-overview-of-the-problem
There is often a need to build new interfaces out of existing
packages.  This is awkward in VHDL because of limited facilities
for "importing" and "exporting" declarations.  The use clause in VHDL 87
provides a general way of importing declarations but the language
does not provide a way to export a declaration imported with a use
clause.  Alternatively, an alias declaration can be used to both
import an export a declaration but the alias declaration is rather
limited in the kinds of declarations it deals with.  

!proposed-solution
We propose to address this problem by generalizing the VHDL alias
declaration.  In VHDL 87 the alias declaration may only be used to
rename objects; we propose to allow aliases for any declared item
with the exception of design unit declared items.

The syntax of an alias declaration is generalized as follows:

   alias_declaration ::=
      ALIAS alias_designator [ : subtype_indication ] IS general_name ;

   alias_designator ::=
      identifier
    | operator_symbol
    | character_literal

   general_name ::=
      name [ parameter_result_profile ]

   parameter_result_profile ::=
      ( [ type_mark { , type_mark } ] [ return type_mark ] )


The semantics of this generalization is as follows:

(1) A parameter result profile is only allowed when creating an
alias for a subprogram (our use of this term includes an "operator") 
or enumeration literal.  It is required when the subprogram or
enumeration literal is overloaded (i.e., when its name is ambiguous).
If provided, the parameter result profile must match the parameter
and result type profile of a subprogram or enumeration literal with
the given name; the subprogram or enumeration literal that so matches
is the one denoted by the general name.  (When we talk about profiles
"matching" here we are of course talking about matching in the sense
of base types.) 

(2) The optional subtype indication is never required and is allowed
only if name denotes an object.

(3) If the optional subtype indication is present the semantics are
exactly as in VHDL 87.

(4) Otherwise, the effect achieved by the alias declaration is to
declare a new designator for an existing declared item.  In addition,
if the declared item being aliased is a type declaration, any
enumeration literals, predefined operations, and physical unit
declarations associated with the type are immediately "aliased"
(without change in designator) immediately following the alias
declaration.

(5) A character literal is only allowed as an alias designator when
the general name denotes an enumeration literal.  An operator symbol
is only allowed when the general name denotes a subprogram.  In this
case, the LRM 2.3.1 rules are followed concerning the nature of the
subprogram.

The ISAC-Approved recommendations for IEEE STD 1076-1987 in IR-0026
and IR-0043 are appropriate for VHDL 92 and these interpretations
are assumed here.  IR-0026 clarifies that there is no meaning
associated with the subtype indication given in an alias declaration
for a scalar object.  (Note that the above generalization of an
alias declaration allows the subtype indication to be optional in
such a circumstance.)  IR-0043 clarifies the meaning of an object
alias where the subtype indication is an unconstrained array type.

!rationale
At least three different approaches can be taken to implementing
VHDL92-DR-10: (1) a "transitive" use clause capability, (2) a
capability to export a declared item made visible by a use clause,
and (3) the approach suggested here.  The "transitive use" clause
would make more sense to us if use clauses were confined to
declarative parts where typical declarations allowed.  This would
allow their definition to be given in terms of (logically anyway)
"inserting" a set of declarations at the point of the use clause.
Concerning new functionality for exporting USEd declarations, it
seems less an impact on the language to generalize the alias
declaration rather than to introduce a new concept into the language.

The idea of a parameter result profile may be seen as additional
language complexity for relatively little gain.  However, this
suggestion is not made solely on the basis of aliasing or import/export. 
We are planning on taking advantage of the notion of a parameter
result profile in allowing attributes on overloaded subprograms
(LCS-0007).  The concept may also be employed in a modified use clause
where the suffix is a subprogram or enumeration literal.  Furthermore,
it is possible that parameter result profile may be part of a
future proposal on pathnames (see LCS-0003).  Finally, we may take
advantage of the parameter result profile idea in marking subprograms
as being "foreign" (i.e., implemented in something other than VHDL,
see VHDL92-DR-13).

The distinguished treatment for aliasing a type is based on the
belief that it is often necessary to obtain a type as well as all
the "basics" associated with the type and that a convenient method
should be provided of doing so.

!lrm-sections-affected TBD
!examples

    package P1 is
       function Is_Zero(signal S : Bit) return Boolean;
       function Is_Zero(signal S : MVL) return Boolean;
       ...
    end P1;

    package P2 is
       alias Character is Std.Standard.Character;
          -- Enumeration literals for Std.Standard.Character
          -- automatically aliased in here
       ...
       alias Is_Zero is Work.P1.Is_Zero(MVL return Boolean);
          -- Picks up second Is_Zero in P1
       ...
    end P2;

!upward-compatibility
This proposal is upward compatible.

!implementation-impact
The impact here is strictly front end and can be implemented using
"soft link" or rename capability built into the symbol table mechanism.

!other-alternatives-considered
As discussed above, a "transitive" use clause as well as an "export
command" were considered as alternate approaches to addressing this
problem.

!miscellaneous-discussion
There are at least three issues that have been associated
with this proposal that we have been unable to address.  One is the lack
of an ability to "import" or "alias" all the items in a package with a
single declaration/specification.  We did put together a proposal
for further generalizing the alias declaration along this line as
follows:

> ... My thought on doing better comes
> three stages.  Stage 1 is take what is there now (in LCS-0008(1)):
> 
>   alias_declaration ::=
>      ALIAS alias_designator [ : subtype_indication ] IS general_name ;
> 
> and make the alias designator optional, i.e.,
> 
>   alias_declaration ::=
>      ALIAS [ alias_designator [ : subtype_indication ] IS ] general_name ;
> 
> The semantics for the case where the alias designator is missing is
> that the alias inherits the simple name, character literal, or
> operator symbol of the general name.  E.g.,
> 
>      alias Work.My_package.My_item;
> 
> means
> 
>      alias My_item is Work.My_package.My_item;
> 
> Stage 2 is that the general name given above allows (semantically)
> a form "package_name.all".  This form is only allowed when the alias
> designator is missing from the alias declaration, i.e.,
> 
>      alias Work.My_package.all;
> 
> is OK but
> 
>      alias My_item is Work.My_package.all;
> 
> is not.  The meaning here is like the creation of same-named aliases
> for all the items in the named package.  I.e.,
> 
>      alias Work.My_package.all;
> 
> means the same as
> 
>      alias I1 is Work.My_package.I1;
>      ...
>      alias Ik is Work.My_package.Ik;
> 
> Where I1, ..., Ik are all the items in Work.My_package.  Finally, in
> Stage 3, drop the special treatment from LCS-0008 that happens
> when you alias types (i.e., automatically alias (without change
> in designator) the associated enumeration literals, predefined
> operations, and physical unit declarations).  There are three reasons
> for this.  One is to improve the parallel/uniformity between the
> USE clause and the ALIAS declaration.  Another is that my original
> proposal for special treatment of types breaks (technically anyway)
> the proposed definition of
> 
>      alias Work.My_package.all;
> 
> in terms of a sequence of alias declarations, one per declared symbol
> in My_package.  Finally, the business about automatic special
> treatment of associated enumeration literals, operators, etc.,
> associated with a type is somewhat unprecedented in the language
> and might stand out as a "wart".  Hence as part of this proposed
> improvement to the original general-aliasing proposal I think we
> should drop the special treatment for aliasing types.
> 

We did not suggest adopting this proposal for two reasons.  The
primary reason was because it did not "feel right" to make the alias
declaration look and act so much like the use clause.  This is particularly
a concern since the difference in effect between these two can be subtle
and perhaps the sort of things many users do not care about.  The
secondary reason is that we do not suspect that, relatively speaking,
the need for ".all" aliasing will arise frequently in practice.
Typically, the provider of a package might piece a package together
using aliasing facilities but the users of the package would not
be concerned with this and won't have much use for this capability
for themselves.  Thus the workaround of aliasing each item each item in
the package is not as terrible as it might seem.

A second issue concerning this proposal that we were unable to solve
concerns the cancelling effect of use clauses.  If P2 builds same-named
aliases for items in P1 and then P3 "use.all's" both P1 and P2,
neither the original declarations or the aliases will be visible due
the cancelling effect of use clauses.  We did not know how to address
this problem in the time we had remaining but further we feel that in
practice with properly constructed packages the need for users to
use.all both the original and new packages should not exist.

A final issue concerns the use clause and the need to be able to
"use" a type and automatically get, e.g., all the enumeration literals
associated with the type.  We observe this would be non-upward-compatible.
It nevertheless may be a good idea but actually we did not have time
to study it carefully.

!open-issues