From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,c890e6ab3fb2c5fc X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,c890e6ab3fb2c5fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-25 12:44:53 PST Newsgroups: comp.lang.ada,comp.lang.c++ Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!gw1.att.com!csn!ncar!gatech!howland.reston.ans.net!EU.net!chsun!mlma11.matrix.ch!user From: Mats.Weber@matrix.ch (Mats Weber) Subject: Re: ADA Objects Help! Message-ID: Sender: usenet@eunet.ch Organization: ELCA Matrix SA References: <3f9g1u$j4m@nps.navy.mil> <3fcs59$70s@nps.navy.mil> <3ff186$c19@gnat.cs.nyu.edu> <3fhggr$11dp@watnews1.watson.ibm.com> <3forgl$11cd@watnews1.watson.ibm.com> Date: Wed, 25 Jan 1995 20:44:53 GMT Xref: nntp.gmd.de comp.lang.ada:18312 comp.lang.c++:88076 Date: 1995-01-25T20:44:53+00:00 List-Id: 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@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