* Types vs subtypes @ 2000-08-28 2:47 Alex Angas 2000-08-28 0:00 ` Richard Riehle 0 siblings, 1 reply; 5+ messages in thread From: Alex Angas @ 2000-08-28 2:47 UTC (permalink / raw) I've been given an Ada project to work on and I'm trying to work out what the difference between using a type or subtype is. Why is myarray an array of st, instead of just making it an array of t in the following declaration? type enum is ( red, green, blue ) ; type t is array( enum ) of natural ; subtype st is t; type myarray is array( enum ) of st; They both seem to compile the same. What am I missing? Thanks for your help, Alex. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Types vs subtypes 2000-08-28 2:47 Types vs subtypes Alex Angas @ 2000-08-28 0:00 ` Richard Riehle 2000-08-29 0:00 ` Marc A. Criley 2000-08-29 6:06 ` Preben Randhol 0 siblings, 2 replies; 5+ messages in thread From: Richard Riehle @ 2000-08-28 0:00 UTC (permalink / raw) Alex Angas wrote: > I've been given an Ada project to work on and I'm trying to work out what > the difference between using a type or subtype is. Why is myarray an array > of st, instead of just making it an array of t in the following declaration? > > type enum is ( red, green, blue ) ; > type t is array( enum ) of natural ; > subtype st is t; > type myarray is array( enum ) of st; > This is something that comes up a lot in my Ada classes. I try to explain it this way: A type has 1) a name 2) a set of operations 3) a set of values 4) a wall between objects of itself and objects of other types with differing type names The last item, " a wall" is important in distinguishing structural equivalence from name equivalence in the Ada type system. A subtype has 1) a name 2) a parent type 3) the set of operations of its parent type 4) either the same set of values of its parent type or a constrained set of values 5) no wall between operations between itself and its parent type 6) no wall between itself and other subtypes derived from its parent or from itself A subtype is structurally equivalent to its parent type and its subtype siblings, but may have a smaller range of legal values. This should not be confused with a derived type where the first four items for a subtype will hold, but not the last two (5 and 6). type T1 is (Red, Orange, Yellow, Green, Blue, Indigo, Violet); type T2 is (Red, Orange, Yellow, Green, Blue, Indigo, Violet); These are both separate types. The properties for a type hold. X : T1; Y : T2; ... X := Y; -- illegal Y := X; -- illegal X : T1(Y); -- illegal; this type conversion not permitted in this case Now, type T3 is new T1; -- could have constrained the range Z : T3; ... X := Z; -- illegal; no structural equivalence permitted for types X := T1(Z); -- legal; T3 is derived from T1 and X and Z are in same derivation Further, subtype T4 is T1 range Green..Violet; subtype T5 is T1; M : T4; P : T5; ... X := M; -- legal; structurally equivalent M := X; -- also legal but potential for constraint error at execution time. P := X; -- legal; no potential for constraint error since subtype range is same as parent Summary. Use subtypes whenever you feel OK about relaxing the typing model. Use types when you want to preserve strong typing. Ada has several features that, when used with care, allow the programmer to relax the type model. It is easier to start with a language design in which the default is strong type and relax that model than to start with a language where the default is weak typing and make it stronger. This is not a complete exposition and not very rigorous computer science, but I hope it helps. Richard Riehle ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Types vs subtypes 2000-08-28 0:00 ` Richard Riehle @ 2000-08-29 0:00 ` Marc A. Criley 2000-08-29 0:00 ` Jean-Pierre Rosen 2000-08-29 6:06 ` Preben Randhol 1 sibling, 1 reply; 5+ messages in thread From: Marc A. Criley @ 2000-08-29 0:00 UTC (permalink / raw) Richard Riehle wrote: >A subtype is structurally equivalent to its parent type and its subtype >siblings, but may have a smaller >range of legal values. Actually, there's a specific situation where this statement could be interpreted as not necessarily being true--depending on how broadly one defines "structural equivalence". And which came as a surprise to us. We had a situation where there was a type Counts is range 0..128; that had a size clause: for Counts'Size use 32; This then had a subtype subtype Indicies is Counts range 1..128; Our expectation was that Counts'Size would be 32, and Indices'Size would be 32. While that was in fact the case for the 'Size of Counts, Indices'Size turned out to be 8. We researched this in the RM (and could find no statement requiring that a type's size be passed on to its subtypes), and also went back to our compiler vendor, and confirmed that this behavior was correct. It was, as Robert Dewar put it, "in pure Ada 95...a nasty omission". While size specification is retained through derivation, it is not through subtyping. And placing a Size specification on a subtype is not permitted by the language. We ended up utilizing the parent type in the external interface, relying on the use of the subytpe throughout the remainder of the module to ensure the proper constraints were obeyed. Marc A. Criley Software Architect Lockheed Martin M&DS ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Types vs subtypes 2000-08-29 0:00 ` Marc A. Criley @ 2000-08-29 0:00 ` Jean-Pierre Rosen 0 siblings, 0 replies; 5+ messages in thread From: Jean-Pierre Rosen @ 2000-08-29 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2186 bytes --] "Marc A. Criley" <marc.a.criley@lmco.com> a �crit dans le message news: 39ABAAE7.3B4BEF29@lmco.com... > We had a situation where there was a > > type Counts is range 0..128; > > that had a size clause: > > for Counts'Size use 32; > > This then had a subtype > > subtype Indicies is Counts range 1..128; > > Our expectation was that Counts'Size would be 32, and Indices'Size would be 32. > While that was in fact the case for the 'Size of Counts, Indices'Size turned out to > be 8. We researched this in the RM (and could find no statement requiring that a > type's size be passed on to its subtypes), and also went back to our compiler > vendor, and confirmed that this behavior was correct. It was, as Robert Dewar put > it, "in pure Ada 95...a nasty omission". While size specification is retained > through derivation, it is not through subtyping. And placing a Size specification > on a subtype is not permitted by the language. > > We ended up utilizing the parent type in the external interface, relying on the use > of the subytpe throughout the remainder of the module to ensure the proper > constraints were obeyed. It seems that you assumed that *variables* declared of subtype Indices would use Indices'Size bits - and this is a misunderstanding. Try this: with Text_Io; use Text_Io; procedure Essai is type Counts is range 0..128; for Counts'Size use 32; subtype Indices is Counts range 1..128; V_Counts : Counts; V_Indices : Indices; begin Put_Line ("Sizes:"); Put_Line ("Counts:" & Integer'Image (Counts'Size)); Put_Line ("Indices:" & Integer'Image (Indices'Size)); Put_Line ("V_Counts:" & Integer'Image (V_Counts'Size)); Put_Line ("V_Indices:" & Integer'Image (V_Indices'Size)); end Essai; You'll see (with Gnat) that V_Indices has size 32. In short: the 'Size for a (sub)type tells you the minimum number of bits required for it according to Shannon's theorem. If you want to check the size used by a variable, declare a variable and take its 'size. -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Types vs subtypes 2000-08-28 0:00 ` Richard Riehle 2000-08-29 0:00 ` Marc A. Criley @ 2000-08-29 6:06 ` Preben Randhol 1 sibling, 0 replies; 5+ messages in thread From: Preben Randhol @ 2000-08-29 6:06 UTC (permalink / raw) On Mon, 28 Aug 2000 16:20:11 -0700, Richard Riehle wrote: > >This is something that comes up a lot in my Ada classes. I try to explain it >this way: > >A type has > 1) a name > 2) a set of operations > 3) a set of values > 4) a wall between objects of itself and objects of other >types with differing type names > >The last item, " a wall" is important in distinguishing structural equivalence >from name equivalence in the >Ada type system. > >A subtype has > > 1) a name > 2) a parent type > 3) the set of operations of its parent type > 4) either the same set of values of its parent type or a >constrained set of values > 5) no wall between operations between itself and its >parent type > 6) no wall between itself and other subtypes derived from >its parent or from itself > >A subtype is structurally equivalent to its parent type and its subtype >siblings, but may have a smaller >range of legal values. Yes. I like to look at it in this (rough) way in accordance with the syntax : type Height is new Integer; -- ^^^^^^ -- Think of it as a new type. subtype Height is Integer; -- ^^ -- Think of it as it _is_ Integer type and not a new one. -- Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/ "i too once thought that when proved wrong that i lost somehow" - i was hoping, alanis morisette ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-08-29 6:06 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-08-28 2:47 Types vs subtypes Alex Angas 2000-08-28 0:00 ` Richard Riehle 2000-08-29 0:00 ` Marc A. Criley 2000-08-29 0:00 ` Jean-Pierre Rosen 2000-08-29 6:06 ` Preben Randhol
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox