Version 1.2 of ais/ai-00339.txt

Unformatted version of ais/ai-00339.txt version 1.2
Other versions for file ais/ai-00339.txt

!standard 9.04 (05)          03-07-31 AI95-00339/01
!standard 9.04 (08)
!class amendment 03-07-31
!status No Action (10-0-0) 03-10-03
!status work item 03-07-31
!status received 03-01-15
!priority Low
!difficulty Easy
!subject Add use clauses to protected types
!summary
Use clauses are allowed in the definition and body of a protected type.
!problem
It is inconsistent that use_clauses are not allowed in the definition and body of a protected type, but aspect_clauses and pragmas are allowed.
!proposal
Allow use clauses in protected definitions and protected bodies.
!wording
Add use_clause to the list of items allowed as a protected_object_operation and protected_operation_item.
!example
None needed.
!discussion
protected types will never be consistent with packages, as they are a type definition, and nested type definitions cannot be allowed. Therefore, there always will be some declarations not allowed in a protected type definition. Similarly, the body of a protected type is restricted in order to avoid the allocation of any body-specific data. The only question is where to draw the line.
!corrigendum 09.04(05)
protected_operation_declaration ::= subprogram_declaration | entry_declaration | aspect_clause
by:
protected_operation_declaration ::= subprogram_declaration | entry_declaration | aspect_clause | use_clause
!corrigendum 09.04(08)
protected_operation_item ::= subprogram_declaration | subprogram_body | entry_body | aspect_clause
by:
protected_operation_item ::= subprogram_declaration | subprogram_body | entry_body | aspect_clause | use_clause
!ACATS test
Add an ACATS test checking that a use_clause can be used in these contexts.
!appendix

!topic Restriction in private part of protected definition
!reference RM95-9.4(4)
!from Toshitaka Kumano 03-01-15
!keywords protected definition, use clause, use type clause, pragma
!discussion

The syntax

protected_definition ::=
    { protected_operation_declaration }
[ private
    { protected_element_declaration } ]
  end [protected_identifier]

seems too restrictive.

You can declare neither use-clause nor pragma Export in this construct.

package P is
   type T is new Integer;
end P;

with P;
procedure Sample is
   protected X is
      -- cannot use "use P;"
      function Value return Integer;
   private
      -- cannot use "use P;"
      Data : T;
      -- cannot export "Data".
   end X;

   protected body X is
      -- cannot use "use P;"
      function Value return Integer is
      begin
         return Integer (Data);
      end Value;
   end X;

begin
   null;
end Sample;


Prohibiting use-clause here causes non-orthgonal semantics compared
with other constructs, e.g., nested package. The situation unreasonably
demands pragrammers to qualify fully types, literals, or operators,
that is not practical in readability.

As for the pragma, I admit it is not good design of a software.

It is invaluable or indispensable, however, in simple & fast tracing
the (protected) values ("Data" above), without tasking interaction,
especially when the runtime behavior is dubious or too inefficient.

****************************************************************

From: Adam Beneschan
Sent: Wednesday, January 15, 2003  3:41 PM

I agree that there's no good reason not to allow a USE clause here
(other than additional work for compiler implementors :-).

As for exporting a protected component: Aside from the obvious comment
that this would make no sense at all in a protected type declaration
(as opposed to a single protected object declaration), the whole idea
of protected types is that nobody is supposed to be able to access the
components other than the operations in the body of the protected
type, so it doesn't make any sense to allow protected components to be
exported.

> As for the pragma, I admit it is not good design of a software.

If you *really* need this for debugging purposes, why not add a
protected function to the protected type that returns the 'Address of
the component, and then you can call this once and save the address
somewhere and then use that address when you want to trace the value.
Truly horrible software design---but, I submit, no worse than adding
"pragma Export" to a protected component.  Oh, and then yank the
horrible function out when you're done debugging.

****************************************************************

From: Robert Dewar
Sent: Thursday, January 16, 2003  3:03 AM

Note that the syntax in Ada does permit pragmas in general in a protected
definition (since pragmas are allowed between declarations), so an impl
defined Export (e.g.Export_Object) could be syntactically permitted. Yes
it is bogus if there is more than one object (in much the same way that
pragma Export today is bogus in a generic, but is permitted [GNAT always
generates a warning for this latter usage :-)])

****************************************************************

From: Toshitaka Kumano
Sent: Thursday, January 16, 2003  6:06 AM

Adam Beneschan wrote:
> If you *really* need this for debugging purposes, why not add a
> protected function to the protected type that returns the 'Address of
> the component, and then you can call this once and save the address
> somewhere and then use that address when you want to trace the value.

Thank you for the suggestion.

It will work, but it costs more than the pragma in some target OS,
e.g. VxWorks, on which you can examine the value with the exported
symbol quite without other modification.

I admit it is of target-dependent issue, but I *thought* it is too
restrictive that the langage specification prohibited to use the pragma.

Robert Dewar wrote:
> Note that the syntax in Ada does permit pragmas in general in a protected
> definition (since pragmas are allowed between declarations), so an impl
> defined Export (e.g.Export_Object) could be syntactically permitted.

If the statememet above is of a concensus, my first mail was simply wrong
as for pragmas.  Sorry for confusion.

> Yes
> it is bogus if there is more than one object (in much the same way that
> pragma Export today is bogus in a generic, but is permitted [GNAT always
> generates a warning for this latter usage :-)])

As a practitioner, I would say it is nosy for an Ada compiler, at least,
when it is targeted for VxWorks, to warn the very case....

****************************************************************

Editor's note:

I've needed to declare array types in protected types on several occasions.
However, that is not allowed because nested type definitions aren't allowed.
(Given some of the problems that occur when those are allowed, that is a good
thing.)

So, allowing use clauses won't really add any consistency. Given that this
will have costs (especially in the tools that enforce use clause usage rules),
and this is of dubious benefit, I suggest that the idea be dropped.

****************************************************************

Questions? Ask the ACAA Technical Agent