Re: One type for all

Re: One type for all

[czgrr]

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.

Re: One type for all

[Samuel T. Harris]

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!"

Re: One type for all

[Ehud Lamm]

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

Re: One type for all

[Robert Dewar]

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.

Re: One type for all

[Samuel T. Harris]

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!"

Re: One type for all

[Samuel T. Harris]

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!"

Re: One type for all

[Larry Kilgallen]

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... :-)

Re: One type for all

[Robert Dewar]

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.

Re: One type for all

[Samuel T. Harris]

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!"

Re: One type for all

[Keith Thompson]

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.

Re: One type for all

[Keith Thompson]

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.

Re: One type for all

[Robert Dewar]

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.

Re: One type for all

[Tucker Taft]

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

Re: One type for all

[Robert A Duff]

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.

Re: One type for all

[Robert Dewar]

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.

Re: One type for all

[Bill Findlay]

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