* Re: One type for all [not found] <3783E0D2.5D74243@boeing.com> @ 1999-07-08 0:00 ` czgrr 1999-07-09 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 16+ messages in thread From: czgrr @ 1999-07-08 0:00 UTC (permalink / raw) In article <3783E0D2.5D74243@boeing.com>, Robert Jordan <robert.l.jordan@boeing.com> wrote: > This one's got me wondering if I missed a change between Ada83 and > Ada95: I'll say now that I don't know Ada95, but do use Ada83. I'll leave any Ada95-specific comments to others. I'll also say that I have not compiled and tested the code I give here, it's just to show the concepts. So please excuse any typos or other blatantly silly mistakes. (; > If the larger system maintained a duplicate set of types that the parser > used (Possibly using different names), how could I instruct the compiler > to treat one type as an equivilant to another without having to modify > the parser spec or body? [snip] > type int32 is range -32000..32000; > type command_list is > record > Command1: int32; > Command2: int32; > end record; [snip] > type integer_32_type is range -32000..32000; > type Command_Code_Record_Type is > record > Command_01: integer_32_type; > Command_02: integer_32_type; > end record; By defition of the language, int32 and integer_32_type are *different* types. Okay, they inherit operators, etc from universal_integer, since you are effectively saying... type integer_32_type is new Universal_Integer range -32000..32000; Note the "new". This means you can't directly interchange them. That's the whole point of using strong typing; int32 and integer_32_type could represent completely different kinds of data, the compiler doesn't know you want them to be the same. For example... type month is range 1..12; type am_pm_hour is range 1..12; type times_tables is range 1..12; -- at least it was in my day! Does assignment between these make any sense? You could have... subtype integer_32_type is parser.int32; > > I would like to be able to > > with parser; > > in the larger application but use the already existing application > Command_Code_Record_Type to reference parameters and such from the > parser which uses command_list without having to equate each instance of > the records. You could also try the following... type integer_32_type renames parser.int32; type Command_Code_Record_Type renames parser.command_list; although in the case of the latter you would change field names Command_01 and Command_02, which might affect your code if you have used named notation, for example. But later, you can have something like... Command_01 : integer_32_type renames Command_Code_Record_Type.Command_01; or something like that, anyway, I haven't tried it. I prefer the suggestion below in a situation like this. > Common Ada doesn't seem to allow me to do the following: > > in parser: > > procedure get_record(out the_record : command_list) ; > > and in the application, I'd like to do this: > > My_Commands : Command_Code_Record_Type; --Already existing code > parser.get_record(My_Commands); --Desired new action Another possible answer to this is to use a wrapper around parser. To continue your example, you would have something like... package parser_wrapper is -- Procedures and functions which mimic those in the spec of -- parser, but use the other types instead. procedure get_record(out the_record : Command_Code_Record_Type); end package; ----- with parser; package body parser_wrapper is function convert(in parser_data : parser.int32) return integer_32_type is begin -- Base types can be type-cast directly. return integer_32_type(parser_data); end convert; function convert(in parser_data : parser.command_list) return Command_Code_Record_Type is begin -- Record types must be built from their components. -- Same for any other complex structure. return ( Command_01 => convert(parser_data.Command1, Command_02 => convert(parser_data.Command2); end convert; -- Provide convert's to and from each parser type and its -- external equivalent. procedure get_record(out the_record : Command_Code_Record_Type) is parser_the_record : parser.command_list; begin -- Procedures and functions call the parser version with any -- IN parameters convert'ed beforehand, and OUT parameters -- convert'ed afterwards. For IN OUT, use a combination. parser.get_record(parser_the_record); the_record := convert(parser_the_record); end get_record; end parser_wrapper; > It seems to me that if a package is to be truely encapsulated, one > shouldn't have to depend on the names of the types in that package so > long as the data formats line up exactly. Of course, this kind of > action may not be desireable in all circumstances, but it does appear > that Ada acts this way when dealing with standard scalar types > (Standard.Integer and such). Then perhaps the parser package should have been written as a generic! > > It also seems non-OO to have to 'with' the parser spec into the bigger > application at the expense of the types already defined in the > applications spec when the two are exactly the same. Oh yes, I forgot to say... If you use the parser_wrapper package, you have to WITH that *instead of* the parser package. Your code above would become... My_Commands : Command_Code_Record_Type; --Already existing code parser_wrapper.get_record(My_Commands); --Desired new action If you use the renames, you have to repeat them every time or put them in a separate package and WITH (and USE?) that everywhere you want access to your types. Comments on my suggestions, additional suggestions, plus Ada95-specific solutions, anyone? HTH czgrr -- No email, please - reply to the newsgroup. My opinions are not necessarily those of my employer. Use any suggestions at your own risk. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all [not found] <3783E0D2.5D74243@boeing.com> 1999-07-08 0:00 ` One type for all czgrr @ 1999-07-09 0:00 ` Samuel T. Harris 1999-07-10 0:00 ` Ehud Lamm 1999-07-12 0:00 ` Robert Dewar 1 sibling, 2 replies; 16+ messages in thread From: Samuel T. Harris @ 1999-07-09 0:00 UTC (permalink / raw) Types in both Ada 83 and Ada 95 use name-equivalence instead of structural-equivalence (as is found in Pascal). The fact that the type have the same structure and bounds is not relevant. Because the type have distinct declarations is all that matters. One type is Command.Int32 and the other is Some_Package.Integer_32_Type. You have two separate and distinct types. If you want the type to be interchangeble, then use subtypes, although many will reason (and rightly so) that subtypes across packages exposes one to a host of problems since the strong-typing features of Ada are being by-passed. Robert Jordan wrote: > > This one's got me wondering if I missed a change between Ada83 and > Ada95: > > If I had one package that did something interestingly useful: Say, it > parsed command lines or so... That I didn't write but wanted to use as a > component of a larger system. > > If the larger system maintained a duplicate set of types that the parser > used (Possibly using different names), how could I instruct the compiler > to treat one type as an equivilant to another without having to modify > the parser spec or body? > > For example, > > In the parser, there are two types defined: > > type int32 is range -32000..32000; > type command_list is > record > Command1: int32; > Command2: int32; > end record; > > and in the bigger SW, in which I wish to insert the handy parser there > are types already defined as: > > type integer_32_type is range -32000..32000; > type Command_Code_Record_Type is > record > Command_01: integer_32_type; > Command_02: integer_32_type; > end record; > > I would like to be able to > > with parser; > > in the larger application but use the already existing application > Command_Code_Record_Type to reference parameters and such from the > parser which uses command_list without having to equate each instance of > the records. > > Common Ada doesn't seem to allow me to do the following: > > in parser: > > procedure get_record(out the_record : command_list) ; > > and in the application, I'd like to do this: > > My_Commands : Command_Code_Record_Type; --Already existing code > parser.get_record(My_Commands); --Desired new action > > It seems to me that if a package is to be truely encapsulated, one > shouldn't have to depend on the names of the types in that package so > long as the data formats line up exactly. Of course, this kind of > action may not be desireable in all circumstances, but it does appear > that Ada acts this way when dealing with standard scalar types > (Standard.Integer and such). > > It also seems non-OO to have to 'with' the parser spec into the bigger > application at the expense of the types already defined in the > applications spec when the two are exactly the same. > > Any insight would be appreciated. > > Thanks, > Robert Jordan -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-09 0:00 ` Samuel T. Harris @ 1999-07-10 0:00 ` Ehud Lamm 1999-07-12 0:00 ` Samuel T. Harris 1999-07-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 16+ messages in thread From: Ehud Lamm @ 1999-07-10 0:00 UTC (permalink / raw) On Fri, 9 Jul 1999, Samuel T. Harris wrote: > Types in both Ada 83 and Ada 95 use name-equivalence instead > of structural-equivalence Note that when you instantiate a generic a strucutural equivalence is required (according to the generic rules). Ehud Lamm mslamm@pluto.mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-10 0:00 ` Ehud Lamm @ 1999-07-12 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 16+ messages in thread From: Samuel T. Harris @ 1999-07-12 0:00 UTC (permalink / raw) Ehud Lamm wrote: > > On Fri, 9 Jul 1999, Samuel T. Harris wrote: > > > Types in both Ada 83 and Ada 95 use name-equivalence instead > > of structural-equivalence > > Note that when you instantiate a generic a strucutural equivalence is > required (according to the generic rules). > > Ehud Lamm mslamm@pluto.mscc.huji.ac.il > http://purl.oclc.org/NET/ehudlamm <== My home on the web This is true. However, the original poster was refering to type and object declarations and generics were not involved. To be more precise, perhaps I should have said Ada uses name-equivalence for type and object declarations. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-09 0:00 ` Samuel T. Harris 1999-07-10 0:00 ` Ehud Lamm @ 1999-07-12 0:00 ` Robert Dewar 1999-07-12 0:00 ` Larry Kilgallen 1999-07-12 0:00 ` Samuel T. Harris 1 sibling, 2 replies; 16+ messages in thread From: Robert Dewar @ 1999-07-12 0:00 UTC (permalink / raw) In article <3786741C.E73F1124@hso.link.com>, "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > Types in both Ada 83 and Ada 95 use name-equivalence instead > of structural-equivalence (as is found in Pascal). Am I really misremembering Pascal that badly. Surely Pascal has name equivalence, e.g. if you declare two identical record types with different names, they are different types. I think you are confusing name/structural equivalence with the different rules in Pascal about compatibility of types. But perhaps I am remembering wrong ... I'm on vacation so my Pascal texts are out of reach :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-12 0:00 ` Robert Dewar @ 1999-07-12 0:00 ` Larry Kilgallen 1999-07-17 0:00 ` Robert Dewar 1999-07-12 0:00 ` Samuel T. Harris 1 sibling, 1 reply; 16+ messages in thread From: Larry Kilgallen @ 1999-07-12 0:00 UTC (permalink / raw) In article <7mdobd$fu$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > I'm on vacation so my Pascal texts are out of reach :-) Obviously "vacation" is not one of Robert's core competencies... :-) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-12 0:00 ` Larry Kilgallen @ 1999-07-17 0:00 ` Robert Dewar 1999-07-18 0:00 ` Samuel T. Harris 1999-07-18 0:00 ` Keith Thompson 0 siblings, 2 replies; 16+ messages in thread From: Robert Dewar @ 1999-07-17 0:00 UTC (permalink / raw) In article <1999Jul12.193436.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > Obviously "vacation" is not one of Robert's core > competencies... :-) Well I am not sure I get that joke, but I am a little surprised that no one has chimed in here to give the exact Pascal rules from the standard (either one :-) The one reply was about anonymous types, which is really quite a different issue than the basic issue of whether a language uses structural or named type equivalence. Robert Dewar Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-17 0:00 ` Robert Dewar @ 1999-07-18 0:00 ` Samuel T. Harris 1999-07-18 0:00 ` Keith Thompson 1 sibling, 0 replies; 16+ messages in thread From: Samuel T. Harris @ 1999-07-18 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <1999Jul12.193436.1@eisner>, > Kilgallen@eisner.decus.org.nospam wrote: > > Obviously "vacation" is not one of Robert's core > > competencies... :-) > > Well I am not sure I get that joke, but I am a little surprised > that no one has chimed in here to give the exact Pascal rules > from the standard (either one :-) > > The one reply was about anonymous types, which is really quite > a different issue than the basic issue of whether a language > uses structural or named type equivalence. > > Robert Dewar > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't. I did get a private email explaining that "standard" Pascal calls for the anonymous types to be treated as separate type definitions thus removing any ambiguity of the original lanaguage. Each anonymous type is given an internal, unique name and named equivalence is used. My usage of Pascal dates to early 1980's which I suppose was before the "standard" (at least the compiler in use was). Not being familiar with any standard version, my previous post did specify "original Pascal" since that is the one which was ambiguous about the anonymous types. As an aside, one of the attactions of Ada is the fact that the only versions of the language are the standardized versions! -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-17 0:00 ` Robert Dewar 1999-07-18 0:00 ` Samuel T. Harris @ 1999-07-18 0:00 ` Keith Thompson 1999-07-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 16+ messages in thread From: Keith Thompson @ 1999-07-18 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: [...] > Well I am not sure I get that joke, but I am a little surprised > that no one has chimed in here to give the exact Pascal rules > from the standard (either one :-) Oh, all right, if you insist. 8-)} In the Pascal User Manual and Report, third edition (1985) by Jensen and Wirth, section 6.5, Type Compatibility: ] Two types are said to be _compatible_ if any of the following four ] conditions is true. ] ] (a) They are the same type. ] (b) One is a subrange of the other, or both are subranges of the ] same host type. ] (c) Both are set types, their base types are compatible, and either ] both are packed or neither is packed. ] (d) Both are string types with the same number of components. Since this edition is based on the ISO Pascal Standard, I presume the standard itself says essentially the same thing. (I have a copy lying around somewhere, but I can't find it.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-18 0:00 ` Keith Thompson @ 1999-07-19 0:00 ` Robert Dewar 1999-07-18 0:00 ` Keith Thompson ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Robert Dewar @ 1999-07-19 0:00 UTC (permalink / raw) In article <yeciu7hg0oo.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > ] Two types are said to be _compatible_ if any of the > following four conditions is true. > ] > ] (a) They are the same type. > ] (b) One is a subrange of the other, or both are subranges of the > ] same host type. > ] (c) Both are set types, their base types are compatible, and either > ] both are packed or neither is packed. > ] (d) Both are string types with the same number of components. OK, so those are VERY restictive cases. (a) and (b) correspond closely to the Ada rules, and (c) and (d) are very special cases, similar in spirit indeed to the restricted Ada rules. So thanks, it is indeed the case that Pascal does NOT have structural type equivalence, which is what I remembered (any other conclusion would have been a big surprise!) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-19 0:00 ` Robert Dewar @ 1999-07-18 0:00 ` Keith Thompson 1999-07-19 0:00 ` Tucker Taft ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Keith Thompson @ 1999-07-18 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: [...] > So thanks, it is indeed the case that Pascal does NOT have > structural type equivalence, which is what I remembered (any > other conclusion would have been a big surprise!) Right. After I posted the previous article, it occurred to me that the phrase "same type" might be ambiguous -- for example, that two similar record type declarations might be considered to create two names for the same type. Fortunately, section 6 says: If a type representation does not consist only of a type identifier, then it represents an entirely new type. So yes, standard Pascal does not use structural type equivalence, at least not for record types. (Though I seem to recall that some dialects do use structural equivalence.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-19 0:00 ` Robert Dewar 1999-07-18 0:00 ` Keith Thompson @ 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Robert A Duff 1999-07-20 0:00 ` Bill Findlay 3 siblings, 0 replies; 16+ messages in thread From: Tucker Taft @ 1999-07-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > ... > So thanks, it is indeed the case that Pascal does NOT have > structural type equivalence, which is what I remembered (any > other conclusion would have been a big surprise!) I suspect the confusion comes from the early Pascal reports (e.g. <= 2nd ed.), which were in fact ambiguous on the issue of type equivalence, leading some implementations to choose name equivalence, and others to choose structural equivalence. For structured assignment, it required the types to be "identical" but it didn't define that in any rigorous way. The ISO standard opted for name equivalence, but by that time, there were already implementations using structural equivalence. The initial ISO standard was weak enough that it might not have been sufficient to get all implementors to follow the official rules. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-19 0:00 ` Robert Dewar 1999-07-18 0:00 ` Keith Thompson 1999-07-19 0:00 ` Tucker Taft @ 1999-07-19 0:00 ` Robert A Duff 1999-07-20 0:00 ` Robert Dewar 1999-07-20 0:00 ` Bill Findlay 3 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 1999-07-19 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <yeciu7hg0oo.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > ] Two types are said to be _compatible_ if any of the > > following four conditions is true. > > ] > > ] (a) They are the same type. > > ] (b) One is a subrange of the other, or both are > subranges of the > > ] same host type. > > ] (c) Both are set types, their base types are compatible, > and either > > ] both are packed or neither is packed. > > ] (d) Both are string types with the same number of > components. > > So thanks, it is indeed the case that Pascal does NOT have > structural type equivalence, which is what I remembered (any > other conclusion would have been a big surprise!) > > OK, so those are VERY restictive cases. (a) and (b) correspond > closely to the Ada rules, and (c) and (d) are very special > cases, similar in spirit indeed to the restricted Ada rules. In the case of scalars, the rules are not at all like Ada -- in Pascal, all integers may be freely intermixed (except in certain special cases like passing a component of a packed array as a VAR parameter). That is, there is nothing in Pascal equivalent to Ada's "type T is range 1..10;". Pascal only has the equivalent of "subtype S is Integer range 1..10;". For records, you're right -- Pascal uses by-name equivalence. I'm confused about pointers: I thought in: type T = ^Integer; var X: ^Integer; Y: ^Integer; X and Y could be freely assigned to each other, and passed to a parameter of type T. No? Also, note that Keith quoted from a book that came out after the Pascal standard. The original Jensen and Wirth book was rather unclear about type equivalence / compatibility / etc, and was roundly criticized at the time for it. And of course compiler writers did what they liked; the Pascal culture never developed a great deal of respect for standards and compatibility. (I even once used a Pascal compiler in which identifiers were case sensitive! The authors were C programmers, and they did it the way they thought it ought to be done.) - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-19 0:00 ` Robert A Duff @ 1999-07-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1999-07-20 0:00 UTC (permalink / raw) In article <wcciu7gej7r.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > In the case of scalars, the rules are not at all like Ada -- in Pascal, > all integers may be freely intermixed (except in certain special cases > like passing a component of a packed array as a VAR parameter). That > is, there is nothing in Pascal equivalent to Ada's "type T is range > 1..10;". Pascal only has the equivalent of "subtype S is Integer range > 1..10;". No, no, you are answering another question, which is whether Pascal has the same possibilities of defining separate types as in Ada, and of course the answer is no! There is only one integer type in Pascal. But the treatment of subtypes of this one type is as in Ada, I don't see a difference. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-19 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1999-07-19 0:00 ` Robert A Duff @ 1999-07-20 0:00 ` Bill Findlay 3 siblings, 0 replies; 16+ messages in thread From: Bill Findlay @ 1999-07-20 0:00 UTC (permalink / raw) In article <7mttci$edv$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <yeciu7hg0oo.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > ] Two types are said to be _compatible_ if any of the > > following four conditions is true. > > ] > > ] (a) They are the same type. > > ] (b) One is a subrange of the other, or both are subranges of the > > ] same host type. > > ] (c) Both are set types, their base types are compatible, and either > > ] both are packed or neither is packed. > > ] (d) Both are string types with the same number of components. > ... > So thanks, it is indeed the case that Pascal does NOT have > structural type equivalence, which is what I remembered (any > other conclusion would have been a big surprise!) > This is fairly off-topic in comp.lang.ada, but just for the record: while it is true that Pascal does NOT have structural type equivalence, type equivalence and type compatibility are NOT the same relationship. There are three type relationships in Pascal: (a) equivalence: the types denoted by identifiers T1 and T2 are equivalent iff T1 and T2 are the SAME identifier or the two are explicitly equated, thus: "type T2 = T1"; an anonymous type is equivalent to no other type (b) compatibility: as defined above; this is the relationship required between (e.g.) the type of a record's variant selector (~discriminant) and that of a case constant (~literal choice) (c) assignment compatibility: the relationship between the types of the two sides of an assignment (among other things); defined in terms of compatibility (among other things). Equivalence is required (e.g.) between the types of actual & formal VAR params; assignment compatibility between the types of actual & formal VALUE params. All of this was set out in British Standard BS 6192, first promulgated in 1979, and the parent of the ANS and ISO Pascal Standards. There have been essentially no definitional ambiguities in Pascal for the best part of 20 years. Plenty of time for everyone to catch up, one might think, but Pascal never recovered from an onslaught of ignorant deprecation very reminiscent of that directed a little later against Ada. Compiler writers who selectively ignored the Standard only added to the problem. Ada has held out against its detractors much better; in large part, I think, because its progenitors learned from the Pascal experience and ensured that a definitive standard was there from the start. -- Bill Findlay Department of Computing Science The University of Glasgow ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: One type for all 1999-07-12 0:00 ` Robert Dewar 1999-07-12 0:00 ` Larry Kilgallen @ 1999-07-12 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 16+ messages in thread From: Samuel T. Harris @ 1999-07-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <3786741C.E73F1124@hso.link.com>, > "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > > > Types in both Ada 83 and Ada 95 use name-equivalence instead > > of structural-equivalence (as is found in Pascal). > > Am I really misremembering Pascal that badly. Surely Pascal > has name equivalence, e.g. if you declare two identical > record types with different names, they are different types. > I think you are confusing name/structural equivalence with the > different rules in Pascal about compatibility of types. > > But perhaps I am remembering wrong ... > > I'm on vacation so my Pascal texts are out of reach :-) > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't. I refer to the way type structures can be built directly in an variable declaration. The only Ada 83 equivalent is the anonymous array type used in an object declaration and which has special rules which specifies each as a separate type. In Ada, a pointer to an array of records involves at least three type declarations and then an object declaration using the last access type. In Pascal, the object can be declared directly when all the type structure in one "line" of code. What does it mean in Pascal when two objects are declared using the same type structures? Unfortunately, the original Pascal rules did not deal with this situation. Some implementations choose to create internal type names for each such usage. Others did not. This resulting in some implementations enforcing named-equivalence and some allowing the more looser structural-equivalence. Two records with different names _are_ different types. Two objects with the same record structure in their declaration is not so clear. As I recall my college days, the greatest occurance of this "feature" was declaring objects as pointers to things instead of declaring a pointer type and using that. If three objects are declared as pointers to the same type, are the three objects of the same type? Depends on the implementation. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-07-20 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3783E0D2.5D74243@boeing.com> 1999-07-08 0:00 ` One type for all czgrr 1999-07-09 0:00 ` Samuel T. Harris 1999-07-10 0:00 ` Ehud Lamm 1999-07-12 0:00 ` Samuel T. Harris 1999-07-12 0:00 ` Robert Dewar 1999-07-12 0:00 ` Larry Kilgallen 1999-07-17 0:00 ` Robert Dewar 1999-07-18 0:00 ` Samuel T. Harris 1999-07-18 0:00 ` Keith Thompson 1999-07-19 0:00 ` Robert Dewar 1999-07-18 0:00 ` Keith Thompson 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Robert A Duff 1999-07-20 0:00 ` Robert Dewar 1999-07-20 0:00 ` Bill Findlay 1999-07-12 0:00 ` Samuel T. Harris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox