Version 1.2 of si99s/si99-0019-1.txt
!standard 3.9.17 08-10-23 SI99-0019-1/02
!standard 17.9
!class binding interpretation
!status work item 06-09-25
!status received 06-09-25
!priority High
!difficulty Easy
!qualifier Omission
!subject Add method to check if a name is an implicit dereference
!summary
Add An_Implicit_Dereference as an additional Expression_Kind.
!question
There is currently no easy way to determine if a name is interpreted as
an implicit dereference. ASIS applications can do this by analyzing the
name's type, and decide that it is an implicit dereference if it is of
an access type and is used at a place where an access type is not
expected (prefix of a call, selector of a selected component). There
should be some way to tell if an ASIS name is an implicit dereference.
!recommendation
(See summary.)
!wording
* 3.9.17 -- Add the following enumeration literal to Asis.Expression_Kinds:
...
An_Explicit_Dereference, -- 4.1
A_Function_Call, -- 4.1
{An_Implicit_Dereference, -- 4.1}
An_Indexed_Component, -- 4.1.1
...
* 17.9 -- Allow An_Implicit_Dereference as well as An_Explicit_Dereference:
Expression expects an element that has one of the following Expression_Kinds:
An_Explicit_Dereference -- P.ALL
{An_Implicit_Dereference -- P.X, P'Attr, P(...)}
An_Attribute_Reference -- Priv'Base'First
A_Function_Call -- Abc(...) or Integer'Image(...)
An_Indexed_Component -- An_Array(3)
A_Selected_Component -- A.B.C
A_Slice -- An_Array(3 .. 5)
!discussion
Once overload resolution is complete, almost all compilers have an
explicit indication on a node that it is an implicit dereference. As
such, it becomes as syntactically distinct as the distinction between a
paremeterless function call and an identifier, so there is no reason an
implicit dereference should not be given its own Expression_Kind.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent