From pkruchten@Rational.COM Wed Sep 28 01:17:41 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA28990; Wed, 28 Sep 94 01:17:41 EDT Received: from Rational.COM by inmet.camb.inmet.com (4.1/SMI-4.1) id AA09328; Wed, 28 Sep 94 01:17:35 EDT Received: from igor.Rational.COM by Rational.COM (8.6.9/rational-1.0.2) id FAA22371; Wed, 28 Sep 1994 05:17:31 GMT Received: from [89.30.8.203] (pbk_apple) by igor.Rational.COM (4.1/smh-1.0) id AA02022; Tue, 27 Sep 94 22:17:26 PDT Date: Tue, 27 Sep 94 22:17:25 PDT X-Sender: pkruchten@igor (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bobduff@dsd.camb.inmet.com (Bob Duff), taylorb@ajpo.sei.cmu.edu From: pkruchten@Rational.COM (Philippe Kruchten) Subject: Re: More Sex Please, We're French Cc: ada9x-mrt@inmet.com !topic More Sex Please, We're French !reference RM9x-Index;5.0 !reference 94-4792.a taylorb@ajpo.sei.cmu.edu 94-9-27 !from Philippe Kruchten 94-09-27 <> !discussion Ooops, sorry, couldn't resist this one. :-) ------------------------------------------------------------------------ Philippe Kruchten +1(604)231 3132 6857 Wiltshire st pbk@rational.com +1(604)278 5625 fax Vancouver, B.C. V6P5H2 Canada From kst@alsys.com Wed Sep 28 02:44:31 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA10319; Wed, 28 Sep 94 02:44:31 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA12467; Wed, 28 Sep 94 02:44:19 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA10935; Tue, 27 Sep 94 23:43:57 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA18895; Tue, 27 Sep 94 23:44:12 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA16267; Tue, 27 Sep 1994 23:44:09 +0800 Message-Id: <9409280644.AA16267@pulsar.alsys.com> From: kst@alsys.com (Keith Thompson) Date: Tue, 27 Sep 1994 23:44:08 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ada9x-mrt@inmet.com Subject: Re: No Sex Please, We're British Content-Length: 2184 !topic No Sex Please, We're British !reference RM9x-Index;5.0 !reference RM9x-13.5.3(2);5.0 !reference RM9x-13.5.3(5);5.0 !reference 94-4792.a taylorb@ajpo.sei.cmu.edu 94-9-27 !reference 94-4794.a Bob Duff 94-9-27 !reference Gulliver's Travels, Johathan Swift, 1726 !from Keith Thompson 94-09-27 <> !discussion Yes, "byte sex" is a serious term, but 13.5.3(2) doesn't discuss it; it discusses the related but distinct concept of bit ordering. Byte sex is referred to in 13.5.3(5): "If Word_Size > Storage_Unit, the default bit ordering is the same as the ordering of storage elements in a word, when interpreted as an integer." Byte sex refers to the ordering of the bytes within a larger construct, typically a word; bit ordering refers to the ordering of bits within a larger construct, typically a byte or word. I believe the terms "big-endian" and "little-endian" can refer to either bit ordering or byte sex. Note that the bit and byte ordering for a given processor will usually, but not necessarily, be the same. For example, the 680X0 (X >= 2), is consistently big-endian in its byte ordering. The bit ordering as defined by the bit-field instructions (BFINS, etc) is also big-endian, but the bit ordering as defined by the bit instructions (BTST, etc) is little-endian (within a byte). Is forcing big-endian bit ordering for the 680X0 too much of a burden on implementations? I suspect it isn't (after all, most of the bit offset calculations are likely to be static, and a bit field can be a single bit wide) but others with more expertise can answer this better than I can. As for the index entry, if there's going to be a reference to byte sex, the term should be used somewhere in 13.5.3, probably in paragraph 5. Some might argue that the "sex, byte" entry should be deleted from the index, but I kind of like it; it's almost reminiscent of the "happiness" entry in the index of the AWK book. Is there a prize for the earliest "!reference" header? 8-)} -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 /user/kst/.signature: I/O error (core dumped) From eachus@spectre.mitre.org Wed Sep 28 15:32:09 1994 Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA02863; Wed, 28 Sep 94 15:32:09 EDT Received: from mwunix.mitre.org by inmet.camb.inmet.com (4.1/SMI-4.1) id AA13984; Wed, 28 Sep 94 15:31:48 EDT Return-Path: eachus@spectre.mitre.org Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id PAA22104; Wed, 28 Sep 1994 15:31:35 -0400 Received: from localhost (eachus@localhost) by spectre.mitre.org (8.6.4/8.6.4) id PAA12121; Wed, 28 Sep 1994 15:30:13 -0400 Date: Wed, 28 Sep 1994 15:30:13 -0400 From: "Robert I. Eachus" Message-Id: <199409281930.PAA12121@spectre.mitre.org> To: stt@dsd.camb.inmet.com Cc: team_ada@PASCAL.ACM.ORG, ada9x-mrt@inmet.com In-Reply-To: Tucker Taft's message of Wed, 28 Sep 1994 10:09:36 -0400 (EDT) <9409281409.AA08243@dsd.camb.inmet.com> Subject: Indefinite vs. unconstrained and a weird generic issue. !topic indefinite subtypes vs. unconstrained subtypes !reference RM9X-3.2(9);5.0 !reference RM9X-3.3(23);5.0 !reference RM9X-3.3.1(9);5.0 !reference RM9X-3.3.1(22);5.0 !reference RM9X-3.6(10);5.0 !reference RM9X-3.7(26);5.0 <> !discussion I think I now understand this, but it certainly can't be found in one place in the RM. In addition we are making the same mistake as in Ada 83 of having a very special type of objects with no short name. (Records whose type declarations have discriminants with defaults, in Ada 9X this can be shortened? to "composite objects with definite unconstrained nominal subtypes.") Let me review the rules, and then try to tie them to the generic contract issue. (I think I've convinced myself there is only one weird difference from Ada 83 that is not syntactic sugar.) RM9X-3.2(9): "A subtype is called an _unconstrained_ subtype if its type has unknown discriminants, or if its type allows range, index, or discriminant constraints, but the subtype does not impose such a constraint; otherwise the subtype is called a _constrained_ subtype..." -- So far so good. RM9X-3.3(23): "...The object's _actual subtype_ (that is, its subtype) can be more restrictive that the nominal subtype of the view; it always is if the nominal subtype is an _indefinite subtype_. A subtype is an indefinite subtype if it is an unconstrained array subtype, or if it has unknown discriminants or unconstrained discriminants without defaults (see 3.7); otherwise the subtype is a _definite_ subtype (all elementary subtypes are definite subtypes). An indefinite subtype does not by itself provide enough information to create an object; an additional constraint or explicit initialization expression is necessary (see 3.3.1)." -- Here we have a definition of indefinite subtypes which matches that for -- unconstrained subtypes except that it excludes elementary -- subtypes (which covers the case of discriminants in access -- declarations), and excludes records types which have default -- discriminants. RM9X-3.3.1(9): "If a composite object declared by an object_declaration is a constant, or its nominal subtype is an indefinite subtype, or it is aliased (see 3.10), then its constraint is determined by the bounds or discriminants (if any) of its (implicit or explicit) initial value; the object is said to be _constrained by its initial value_. The actual _subtype_ of such an object is determined by this constraint...." -- This is the really confusing paragraph. I think I understand it -- now, but... The key part is the "declared by an object -- declaration" at the beginning. The intent is that a component is -- not declared by an object declaration (even in cases where a -- component declaration is part of an object declaration), so this -- only applies to a record itself and not to its components. -- (How can you have an component declaration in an object declaration? -- If the object is of an anonymous array type.) RM9X-3.3.1(22): "Notes 7 Implicit initial values are not defined for an indefinite subtype." -- Not very useful, but it is a note. Notice up above the "(implicit -- or explicit) initial value", now we find out that the implicit case -- never exists. Right? Wrong! The actual subtype is definite, -- getting the constraints from the initial value. (Is there any -- other reason for this note?) RM9X-3.6(10): "The subtype defined by the subtype_indication of a component_definition (the _component subtype_) shall be a definite subtype." -- This is a much clearer statement of intent. It just looks like -- 3.3.1(9) limits the applicability. It would really help if this -- statement was moved there. RM9X-3.7(26): "A type declared with a known_discriminant_part is said to have _known discriminants; its first subtype is unconstrained. A type declared with an unknown_discriminant_part is said to have _unknown discriminants_. A type without a discriminant_part has no discriminants, unless it is a derived type; if derived, such a type has the same sort of discriminants (known, unknown, or none) as its parent (or ancestor) type. A tagged class-wide type also has _unknown discriminants_. Any subtype of a type with unknown discriminants is an unconstrained and indefinite subtype (see 3.2 and 3.3.1)." -- The last two sentences here also seem out-of-place, or at least as -- if they should be repeated elsewhere. Would it hurt to in 3.3(23) -- say "if it has unknown discriminants (such as a class-wide type) -- or... "? -- Be that as it may, the real reason for posting this is generic -- formal type parameter matching. Let's call the unnamed class of -- record types "mutant" types. Then we have: Matches "type foo is private" or "type foo is new bar": constrained types unconstrained scalar types mutant types Matches "type foo(<>) is private" or "type foo(<>) is new bar": all non-limited types including the above.** Matches "type foo is tagged private" or "type foo is new bar with private" any tagged type but not any classwide type. Matches "type foo(<>) is tagged private" or ??? any tagged or classwide type. ** Now back to the "type foo(<>) is private" case. Given a generic formal object parameter or a parameter of type foo on some subprogram, I can declare objects of the type in the body of the generic unit, as long as I provide an initial value: Fubar: Foo := Foo_Parameter; Any such object is constrained by the actual subtype of the initial value. However, if the actual type corresponding to Foo is a mutant type I can still assign any value of type Foo to it. Or can I? Which rules govern here? Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From johnson@halley.aero.org Wed Sep 28 15:39:21 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA03237; Wed, 28 Sep 94 15:39:21 EDT Received: from halley.aero.org by inmet.camb.inmet.com (4.1/SMI-4.1) id AA14233; Wed, 28 Sep 94 15:39:18 EDT Date: Wed, 28 Sep 1994 12:37:15 -0700 Message-Id: <94092812371520@halley.aero.org> From: johnson@halley.aero.org (Wowbagger) To: ada9x-mrt@inmet.com Subject: Child Visibility into Parent Body X-Vms-To: smtp%"ada9x-mrt@inmet.com" X-Vms-Cc: kerner,johnson !topic Child Visibility into Parent Body !reference RM9X-10.1;5.0 !from Richard Johnson 94-09-27 !keywords child,visibility <> !discussion In the Rationale Part II, Section 10.1.1, it is stated that "The entities in a parent's body are never visible in a child unit." There are times when using a data item or routine inside the body of the parent is desirable. How can a child be written such that it uses an existing procedure located in the body of its parent? As an example (pardon all of the ellipses): package sort_routines is ... procedure merge_sort(...); ... end sort_routines; package body sort_routines is procedure swap (...) is ... end swap; procedure merge_sort (...) is begin ... swap(...); ... end merge_sort; end sort_routines; procedure sort_routines.quick_sort (...) is begin ... swap (...); -- This is illegal! ... end sort_routines.quick_sort; The only thing I can figure is that you must rewrite the body for sort_routines and move the swap routine (and any other nested utility routines) into a private child. (Of course, you don't want to move swap into the spec of sort_routines). While you are there, you might as well move merge_sort into a public child. Is there better way that does not impact the parent as much? Rj From bobduff@dsd.camb.inmet.com Wed Sep 28 16:32:16 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06374; Wed, 28 Sep 94 16:32:16 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA16354; Wed, 28 Sep 94 16:32:15 EDT Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06330; Wed, 28 Sep 94 16:30:56 EDT Date: Wed, 28 Sep 94 16:30:56 EDT From: bobduff@dsd.camb.inmet.com (Bob Duff) Message-Id: <9409282030.AA06330@dsd.camb.inmet.com> To: eachus@spectre.mitre.org Cc: stt@dsd.camb.inmet.com, team_ada@PASCAL.ACM.ORG, ada9x-mrt@inmet.com In-Reply-To: <199409281930.PAA12121@spectre.mitre.org> (eachus@spectre.mitre.org) Subject: Re: Indefinite vs. unconstrained and a weird generic issue. !topic indefinite subtypes vs. unconstrained subtypes !reference RM9X-3.2(9);5.0 !reference RM9X-3.3(23);5.0 !reference RM9X-3.3.1(9);5.0 !reference RM9X-3.3.1(22);5.0 !reference RM9X-3.6(10);5.0 !reference RM9X-3.7(26);5.0 !reference 94-4799.a Robert I. Eachus 94-9-28 <> !discussion > ** Now back to the "type foo(<>) is private" case. Given a generic > formal object parameter or a parameter of type foo on some > subprogram, I can declare objects of the type in the body of the > generic unit, as long as I provide an initial value: > > Fubar: Foo := Foo_Parameter; > > Any such object is constrained by the actual subtype of the initial > value. However, if the actual type corresponding to Foo is a mutant > type I can still assign any value of type Foo to it. Or can I? Which > rules govern here? In such an *instance* you can assign any value of type Foo to Fubar -- the object is not constrained by its initial value. Generic bodies are not executed, so the rule about constraining by initial values does not apply to them. At run-time, the properties of the actual are all that matter. By the way, around here we call those things "mutable" types. I don't think people want more terms in the RM, but it might be a good idea to define it in the AARM, so language lawyers have a term to use when discussing these animals. - Bob From bobduff@dsd.camb.inmet.com Wed Sep 28 16:38:34 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06741; Wed, 28 Sep 94 16:38:34 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA16556; Wed, 28 Sep 94 16:38:32 EDT Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06643; Wed, 28 Sep 94 16:37:08 EDT Date: Wed, 28 Sep 94 16:37:08 EDT From: bobduff@dsd.camb.inmet.com (Bob Duff) Message-Id: <9409282037.AA06643@dsd.camb.inmet.com> To: johnson@halley.aero.org Cc: ada9x-mrt@inmet.com In-Reply-To: <94092812371520@halley.aero.org> (johnson@halley.aero.org) Subject: Re: Child Visibility into Parent Body !topic Child Visibility into Parent Body !reference RM9X-10.1;5.0 !from Richard Johnson 94-09-27 !keywords child,visibility !reference 94-4800.a Wowbagger 94-9-28 !from Bob Duff <> !discussion > In the Rationale Part II, Section 10.1.1, it is stated that "The entities in a > parent's body are never visible in a child unit." There are times when using a > data item or routine inside the body of the parent is desirable. As you surmise below, the intended way to do that is to make the thing a private child, instead of putting it in the body. > ...How can a > child be written such that it uses an existing procedure located in the body > of its parent? As an example (pardon all of the ellipses): > > package sort_routines is > ... > procedure merge_sort(...); > ... > end sort_routines; > > package body sort_routines is > procedure swap (...) is > ... > end swap; > > procedure merge_sort (...) is > begin > ... > swap(...); > ... > end merge_sort; > end sort_routines; > > procedure sort_routines.quick_sort (...) is > begin > ... > swap (...); -- This is illegal! > ... > end sort_routines.quick_sort; > > The only thing I can figure is that you must rewrite the body for sort_routines > and move the swap routine (and any other nested utility routines) into a > private child. (Of course, you don't want to move swap into the spec of > sort_routines). While you are there, you might as well move merge_sort into a > public child. Is there better way that does not impact the parent as much? No. Note that making swap into a private child requires changing the body of sort_routines, but does *not* require changing the spec, so clients will not need to be recompiled. You would *not* want to make Merge_Sort into a public child, unless you were willing to pay the probably much higher cost of changing all the clients. - Bob From gary@alsys.com Wed Sep 28 20:50:12 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA12201; Wed, 28 Sep 94 20:50:12 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA25688; Wed, 28 Sep 94 20:50:03 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA12390; Wed, 28 Sep 94 17:49:38 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA24104; Wed, 28 Sep 94 17:49:52 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA23687; Wed, 28 Sep 1994 17:49:49 +0800 Date: Wed, 28 Sep 1994 17:49:49 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9409290049.AA23687@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Re: undeclared inherited operations Content-Length: 2639 !topic undeclared inherited operations !reference AARM-7.3.1(7.p); 5.0 !reference AARM-7.3.1(6);5.0 !reference AARM-12.3(18.a);5.0 !reference 94-4678.a Antoine Bertier !reference 94-4683.a Bob Duff 94-9-2 !reference 94-4742.a Antoine Bertier 94-9-14 !reference 94-4778.a Bob Duff 94-9-22 !from Gary Dismukes 94-9-28 <> !discussion Bob, in your recent response to Antoine I believe you made an error in stating that his two examples are different: > > So in practice is there a difference between: > > > > package P is > > package Inner is > > type T is null record; > > private > > procedure Op (X : T); -- (1) > > end Inner; > > > > type NT is new Inner.T; > > procedure Op(X : NT); -- (2) overrides (1) > > end P; My understanding is that procedure Op does not override in this case, because the parent subprogram never becomes visible within the immediate scope of the type NT, and hence the inherited Op will never be declared. > > > > and > > generic > > package G is > > type T is null record; > > private > > procedure Op(X : T); -- (1 g) > > end G; > > > > with G; > > package P is > > package Inner is new G; -- (1 i) > > > > type NT is new Inner.T; > > procedure Op(X : NT); -- (2) overrides (1 i) ???? > > No, this one does not override. > Agreed. > > end P; > > Yes, there is a difference between the above two examples. > > > Somehow I would be surprised if in the second example (2) did not override > > (1 i) > > Yes, that is somewhat surprising. However, there's a difference between > the two examples: In the first (non-generic) example, the body if Inner > is physically inside the body of P, so the programmer sees them both > together -- Inner and P "know about" each other. In the second > (generic) example, on the other hand, the body of G and the body of P > are physically separate from each other, and are likely to be written by > two different programmers. The programmer of P shouldn't have to know > about the private part of G in order to know whether he is accidentally > overriding something. > I'm not sure what rules you're appealing to here. It's not a question of whether the units are physically separate or whether they "know about" each other. What matters is whether an inherited subprogram is ever declared. Or is there some other subtlety of the rules that I'm missing? > > Antoine Bertier > > bertier@alsys.fr > > - Bob -- Gary