Re: ADA Objects Help!

[Mats.Weber@matrix.ch (Mats Weber)]

In the rest of this message, I assume that type and exception declarations
are not allowed in the visible part of package types.

In article <3forgl$11cd@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote:

> In article <Mats.Weber-1901951739360001@mlma11.matrix.ch>,
> Mats.Weber@matrix.ch (Mats Weber) writes: 
> 
> |> In article <3fhggr$11dp@watnews1.watson.ibm.com>,
ncohen@watson.ibm.com wrote: 
> |>
> |> > Because, unlike task units, package units export declarations for use
> |> > outside.
> |>
> |> Well, tasks export entries, which are usable outside just like subprograms
> |> exported from packages.
> 
> True enough.  The entries are per-type entities, whose declarations are
> elaborated once for each task type.  (This is noticeable by the fact that
> entry-family discrete ranges are elaborated once per task type, not once
> for each object of the type.) Entities declared in the declarative part
> of the task body are per-object entities, whose declarations are
> elaborated once per object.

The same rules can be adopted for package types (it's probably the only
reasonable choice anyway).

> The distinction I was trying to make (alhtough I wasn't very clear about
> it) was about per-object entities: The entities declared in a package-
> type declaration would be exported by each object in the package type,
> unlike the per-object entities of a task type.

I must be missing something here. I see entries as belonging to task
_objects_, not task _types_. If you write

   procedure P renames T.E;

then P denotes the E entry of the task _object_ T. Moreover, you cannot
refer to an entry of a task type directly. You need a task object.

> |> >    package type PT is  -- THIS IS NOT VALID ADA XX for XX <= 95 !!!!!!
> |> >       N: Integer := [some nonstatic expression];
> |> >       type T is array (1 .. N) of Integer;
> |> >    end PT;
> |> >
> |> >    Package_1, Package_2: PT;
> |>
> |> The declaration for N does not cause a problem. It would be treated just
> |> like a record component declaration with a default initial value (i.e. the
> |> nonstatic expression is evaluated at each elaboration of a PT).
> 
> This is beginning to look suspiciously like a generic package.  Generic
> templates are the only program units in Ada with the property that
> declarations inside the program-unit declaration are not elaborated as
> part of the elaboration of the program-unit declaration.

To me it looks more like a record type than like a generic package.
Declarations inside the visible part are elaborated at the type
declaration, but not the default initial values, just like for records.
Example:

   package type T is   -- not legal Ada
      N : Integer range 0 .. Max := Initial;
   end T;

is almost equivalent to

   type T is
      record
         N : Integer range 0 .. Max := Initial;
      end record;

I could have written the proposal in my thesis using record types and
allowing procedures as record components (like in N. Cohen's paper), but I
wanted a construct that could express ADTs in a very similar way whether
that ADT was concurrent or not. (I also wanted to be able to export
generic subprograms from my package types, for reasons I won't explain
here). Thus package types and task types.

Another solution preserving the symmetry would be record types + a change
in syntax for task types:

   type T is
      task
         entry A;
      end task;

which would remove the dissymmetry between Ada's task types and other
types. But these considerations are purely syntactical and of limited
interest.

> The term package type is beginning to look like a misnomer.  The
> instances of these types are far more restricted than packages are.
> In fact they are even more restricted than generic packages.
> A package that cannot provide types is little more than a record.

This is a matter of taste, I guess. One similar thing I don't like in Ada
is that a task cannot be a library unit.

Mats