Typing in Ada

Typing in Ada

[Empit]

From typing point of view, how strong is Ada than C?

or

Which is the most strongly typed language.

Responses appreciated

Re: Typing in Ada

[Poul-Erik Andreasen]

On 31 May 2004 06:32:39 -0700
empit@rediffmail.com (Empit) wrote:

> From typing point of view, how strong is Ada than C?
> 
> or
> 
> Which is the most strongly typed language.

Ada. C is weak typed langauge. 


-- 
Poul-Erik Andreasen

http://www.linux-service.dk
http://www.pea.dk 

Re: Typing in Ada

[Jeffrey Carter]

Empit wrote:
> From typing point of view, how strong is Ada than C?
> 
> or
> 
> Which is the most strongly typed language.

Why not try them and see?

procedure Strongly_Typed is
    type I1 is new Integer;
    type I2 is new Integer;
    type I3 is range -100 .. 100;

    V1 : I1 := 3;
    V2 : I2 := 4;
    V3 : I3;
begin -- Strongly_Typed
    V3 := V1 + V2;
end Strongly_Typed;

C:\Code>gcc -c strongly_typed.adb
strongly_typed.adb:10:13: invalid operand types for operator "+"
strongly_typed.adb:10:13: left operand has type "I1" defined at line 2
strongly_typed.adb:10:13: right operand has type "I2" defined at line 3

int main () { /* I cannot call this Strongly_Typed */
    typedef int   I1;
    typedef int   I2;
    typedef short I3;

    I1 V1 = 3;
    I2 V2 = 4;
    I3 V3;

    V3 = V1 + V2;
    return 0;
}

C:\Code>gcc -c strongly_typed.c
[no messages]

Which do you think is more strongly typed?

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
@newsread2.news.pas.earthlink.net:

> procedure Strongly_Typed is
>     type I1 is new Integer;
>     type I2 is new Integer;
>     type I3 is range -100 .. 100;
[snip]
> 
> int main () { /* I cannot call this Strongly_Typed */
>     typedef int   I1;
>     typedef int   I2;
>     typedef short I3;

This isn't an entirely fair comparison because in C, typedef doesn't 
introduce a new type it simply creates a new name for an existing type. In 
Ada, it would be more similar to using a subtype, perhaps. Something like

     subtype I1 is Integer;

In any event to create a new type in C you need to introduce a structure. In 
fact, different structures do have different types:

typedef struct {
  int x;
} A;

typedef struct {
  int x;
} B;

int main()
{
  A a;
  B b;

  a = b;  // Error. A and B are different types.

  ...

I'm not sure if there is a formal definition of strong typing or not. I've 
always thought that it had to do with the property of every expression and 
variable having a well defined type. If so, that is as true of C as it is of 
Ada (in some ways its even more true of C because in C literal numbers have 
specific types... there is no "universal integer" type used, for example, for 
integer literals). The real difference is that C does a bunch of automatic 
type conversions and, furthermore, normally performs these conversions 
without checking if the converted value will fit into the target type. I'm 
not sure that's a strong typing issue, however.

Peter

Re: Typing in Ada

[tmoran]

>In any event to create a new type in C you need to introduce a structure. In
>fact, different structures do have different types:
  How would you do in C the equivalent of

  type Vars is (x,y);
  function Image(Var : Vars) return String is ...
  package Polys is new Multinom(Vars, Image);
  use Polys;

  A : Polys.Multinomials
        := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0*y**4;
  B : Polys.Multinomials := x**2 - 2.0*x**1*y**1 + y**2;
  ...
  Put_Line("Product is " & Image(A*B));

Re: Typing in Ada

[Nick Roberts]

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...

> ...
> This isn't an entirely fair comparison because in C,
> ...
>
> I'm not sure if there is a formal definition of strong
> typing or not.
> ...

Hehe. I'll think one would find, in practice, that most Ada programs tend to
be far more strongly typed than C programs. That is to say that in most Ada
programs it is typical to have constructions such as:

   type Apples is range 0..100;
   type Oranges is range 0..200;

   A: Apples;
   O: Oranges;

whereas in typical C programs you either get:

   typedef int Apples;
   typedef int Oranges;

   Apples a;
   Oranges o;

or more often than not simply:

   int a;
   int o;

In either case, in Ada, the easy mistake:

   A := O;

will be caught by the compiler, whereas in either of the C constructions:

   a = o;

will not.

I think this is the important point about 'strong' typing. It is one aspect
of the basic principle that the more information you give the compiler, the
more bugs it can catch for you.

One more point. I encourage Ada programmers to use the style, where
appropriate, of declaring the type of a literal by using a qualification.
For example, suppose we know there is an 'Eat' procedure for Apples (but we
are perhaps unsure whether Oranges has an 'Eat' or not). To eat ten apples,
it would be prudent to write:

   Eat( Apples'(10) ); -- (1)

rather than just:

   Eat( 10 ); -- (2)

because if it so happens that there is an 'Eat' for Oranges, and it also so
happens that the Eat for Apples has got hidden or commented out or whatever,
the compiler would catch (1), but it would wrongly eat 10 oranges if we
simply wrote (2). Of course, if boths Eats exist and are directly visible,
the qualification would be one way to disambiguate the call.

-- 
Nick Roberts

Re: Typing in Ada

[Alexander E. Kopilovich]

Sorry, can't resist -:)

Empit wrote:

> From typing point of view, how strong is Ada than C?

At first glance it may seem that Ada requires more typing - texts in C look
more condensed (for example, identifiers are typically shorter, famous "++",
"+=" etc. are used everywhere). But when you take into account typing during
debugging, the conclusion changes to the opposite.

> or
>
> Which is the most strongly typed language.

Surely C - again, during debugging - everyone knows that in the heat of
debugging the keys are hit (sometimes) most strongly.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Typing in Ada

[Peter C. Chapin]

"Nick Roberts" <nick.roberts@acm.org> wrote in
news:2i1t1lFij4g5U1@uni-berlin.de: 

> Hehe. I'll think one would find, in practice, that most Ada programs
> tend to be far more strongly typed than C programs. That is to say that
> in most Ada programs it is typical to have constructions such as:
> 
>    type Apples is range 0..100;
>    type Oranges is range 0..200;
> 
>    A: Apples;
>    O: Oranges;
> 
> whereas in typical C programs you either get:
> 
>    typedef int Apples;
>    typedef int Oranges;
> 
>    Apples a;
>    Oranges o;

Yes, Ada provides ranges as distinct types without automatic conversions 
and that's a nice feature. In theory you could get some of the same 
benifits in C by introducing an abstract type (as a structure) to hold a 
range. It could be done much more nicely in C++ using templates, 
overloaded operators, and other C++ features. The reality is, though, that 
many C (or C++) programs don't bother. Perhaps they should.

It's not clear to me how all this relates to the concept of strong typing. 
I guess it would be helpful to have a precise definition of that term. It 
sounds like from what we've said here that strong typing more a matter of 
programming style than a language feature... at least where C and Ada are 
concerned. Is that a valid conclusion?

Peter

Re: Typing in Ada

[Peter C. Chapin]

tmoran@acm.org wrote in news:_KOuc.24339$IB.6225@attbi_s04:

>   How would you do in C the equivalent of
> 
>   type Vars is (x,y);
>   function Image(Var : Vars) return String is ...
>   package Polys is new Multinom(Vars, Image);
>   use Polys;
> 
>   A : Polys.Multinomials
>         := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0
*y**4;
>   B : Polys.Multinomials := x**2 - 2.0*x**1*y**1 + y**2;
>   ...
>   Put_Line("Product is " & Image(A*B));

Are you asking me to show you symbolic polynomical manipulation code in C? 
I don't understand how that bears on the question of how strongly typed C 
is. In any case your example uses features like generic instantiation and 
operator overloading that could be more directly mapped to C++. Would you 
say that C++ is more strongly typed than C?

Peter

Re: Typing in Ada

[David C. Hoos, Sr.]

But both examples for C disregard the fact that int, enum,
and char can be freely mixed, something that Ada would
never allow.

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...
> Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
> @newsread2.news.pas.earthlink.net:
>
> > procedure Strongly_Typed is
> >     type I1 is new Integer;
> >     type I2 is new Integer;
> >     type I3 is range -100 .. 100;
> [snip]
> >
> > int main () { /* I cannot call this Strongly_Typed */
> >     typedef int   I1;
> >     typedef int   I2;
> >     typedef short I3;
>
> This isn't an entirely fair comparison because in C, typedef doesn't
> introduce a new type it simply creates a new name for an existing type. In
> Ada, it would be more similar to using a subtype, perhaps. Something like
>
>      subtype I1 is Integer;
>
> In any event to create a new type in C you need to introduce a structure.
In
> fact, different structures do have different types:
>
> typedef struct {
>   int x;
> } A;
>
> typedef struct {
>   int x;
> } B;
>
> int main()
> {
>   A a;
>   B b;
>
>   a = b;  // Error. A and B are different types.
>
>   ...
>
> I'm not sure if there is a formal definition of strong typing or not. I've
> always thought that it had to do with the property of every expression and
> variable having a well defined type. If so, that is as true of C as it is
of
> Ada (in some ways its even more true of C because in C literal numbers
have
> specific types... there is no "universal integer" type used, for example,
for
> integer literals). The real difference is that C does a bunch of automatic
> type conversions and, furthermore, normally performs these conversions
> without checking if the converted value will fit into the target type. I'm
> not sure that's a strong typing issue, however.
>
> Peter
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>

Re: Typing in Ada

[David C. Hoos, Sr.]

But both examples for C disregard the fact that int, enum,
and char can be freely mixed, something that Ada would
never allow.

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...
> Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
> @newsread2.news.pas.earthlink.net:
>
> > procedure Strongly_Typed is
> >     type I1 is new Integer;
> >     type I2 is new Integer;
> >     type I3 is range -100 .. 100;
> [snip]
> >
> > int main () { /* I cannot call this Strongly_Typed */
> >     typedef int   I1;
> >     typedef int   I2;
> >     typedef short I3;
>
> This isn't an entirely fair comparison because in C, typedef doesn't
> introduce a new type it simply creates a new name for an existing type. In
> Ada, it would be more similar to using a subtype, perhaps. Something like
>
>      subtype I1 is Integer;
>
> In any event to create a new type in C you need to introduce a structure.
In
> fact, different structures do have different types:
>
> typedef struct {
>   int x;
> } A;
>
> typedef struct {
>   int x;
> } B;
>
> int main()
> {
>   A a;
>   B b;
>
>   a = b;  // Error. A and B are different types.
>
>   ...
>
> I'm not sure if there is a formal definition of strong typing or not. I've
> always thought that it had to do with the property of every expression and
> variable having a well defined type. If so, that is as true of C as it is
of
> Ada (in some ways its even more true of C because in C literal numbers
have
> specific types... there is no "universal integer" type used, for example,
for
> integer literals). The real difference is that C does a bunch of automatic
> type conversions and, furthermore, normally performs these conversions
> without checking if the converted value will fit into the target type. I'm
> not sure that's a strong typing issue, however.
>
> Peter
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>

Re: Typing in Ada

[David C. Hoos]

But both examples for C disregard the fact that int, enum,
and char can be freely mixed, something that Ada would
never allow.

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...
> Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
> @newsread2.news.pas.earthlink.net:
>
> > procedure Strongly_Typed is
> >     type I1 is new Integer;
> >     type I2 is new Integer;
> >     type I3 is range -100 .. 100;
> [snip]
> >
> > int main () { /* I cannot call this Strongly_Typed */
> >     typedef int   I1;
> >     typedef int   I2;
> >     typedef short I3;
>
> This isn't an entirely fair comparison because in C, typedef doesn't
> introduce a new type it simply creates a new name for an existing type. In
> Ada, it would be more similar to using a subtype, perhaps. Something like
>
>      subtype I1 is Integer;
>
> In any event to create a new type in C you need to introduce a structure.
In
> fact, different structures do have different types:
>
> typedef struct {
>   int x;
> } A;
>
> typedef struct {
>   int x;
> } B;
>
> int main()
> {
>   A a;
>   B b;
>
>   a = b;  // Error. A and B are different types.
>
>   ...
>
> I'm not sure if there is a formal definition of strong typing or not. I've
> always thought that it had to do with the property of every expression and
> variable having a well defined type. If so, that is as true of C as it is
of
> Ada (in some ways its even more true of C because in C literal numbers
have
> specific types... there is no "universal integer" type used, for example,
for
> integer literals). The real difference is that C does a bunch of automatic
> type conversions and, furthermore, normally performs these conversions
> without checking if the converted value will fit into the target type. I'm
> not sure that's a strong typing issue, however.
>
> Peter
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>

Re: Typing in Ada

[Nick Roberts]

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAD66E1E08Bpchapinsovernet@207.106.92.237...

> ...
> It's not clear to me how all this relates to the concept of strong
> typing.

I think technically strong typing is about explicit type conversion, so
that:

   A := O;
   ... A+O ...

is not permitted, and one has to write:

   A := Apples(O);
   ... A+Apples(O) ...

instead. I think this is the definition generally adopted in computer
science.

> I guess it would be helpful to have a precise definition of that term.
> It sounds like from what we've said here that strong typing more a
> matter of programming style than a language feature ...

I would certainly say that that is where it matters. It doesn't matter if a
programmer language has some wonderful feature if, in practice, nobody ever
uses it.

> ... at least where C and Ada are concerned. Is that a valid
> conclusion?

It seems reasonable to suppose that if C had always included a convenient
facility for introducing differentiated types, this facility would have been
used in practice. I think you will find the following paper (it's a PDF)
very interesting with regard to the ongoing arguments about introducing such
a facility to SQL:

   http://www.jeffsutherland.com/x3h2/97-094.pdf

-- 
Nick Roberts

Re: Typing in Ada

[Hyman Rosen]

Nick Roberts wrote:
 > That is to say that in most Ada
> programs it is typical to have constructions such as:
>    type Apples is range 0..100;
>    type Oranges is range 0..200;

Is it really? The very fact that you have named these types as
you did suggests that the appplicability of ranged types is quite
limited. In a real program that does something useful, what kinds
of things do you want to count up to 100 but not to 101? To 200
but not to 201? Can you give examples from some of your real code?

> In either case, in Ada, the easy mistake:
>    A := O;
> will be caught by the compiler, whereas in either of the C constructions:
>    a = o;
> will not.

I think it's more likely that a type with a limited number of
values would be represented as an enumeration, in which case
the errant construct would be caught by C as well.

Re: Typing in Ada

[Hyman Rosen]

Larry Kilgallen wrote:
> Apples and Oranges are typically used in discussions, but limiting
> the range from 0 to 101 is quite common if you are counting votes
> in the US Senate.  Or 0 to 100 and treat the tiebreaker situation
> like the special case that it is.

Until Puerto Rico (or Iraq!) becomes a state.

> A count of 0 to 435 (437?) House votes likewise has limited range,
> and there is no situation in which the two are to be added (unlike
> the corresponding Massachusetts State Government votes).

Yes, you're safer there, since that number will not change even if a
new state is added.

Nevertheless, I submit that your examples actually demonstrate my
point more than they do yours.

Re: Typing in Ada

[Larry Kilgallen]

In article <9ZRuc.8410$hB2.7017@nwrdny03.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Nick Roberts wrote:
>  > That is to say that in most Ada
>> programs it is typical to have constructions such as:
>>    type Apples is range 0..100;
>>    type Oranges is range 0..200;
> 
> Is it really? The very fact that you have named these types as
> you did suggests that the appplicability of ranged types is quite
> limited. In a real program that does something useful, what kinds
> of things do you want to count up to 100 but not to 101? To 200
> but not to 201? Can you give examples from some of your real code?

Apples and Oranges are typically used in discussions, but limiting
the range from 0 to 101 is quite common if you are counting votes
in the US Senate.  Or 0 to 100 and treat the tiebreaker situation
like the special case that it is.

A count of 0 to 435 (437?) House votes likewise has limited range,
and there is no situation in which the two are to be added (unlike
the corresponding Massachusetts State Government votes).

Re: Typing in Ada

[tmoran]

>>   type Vars is (x,y);
>>   A : Polys.Multinomials
>>         := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0
>Are you asking me to show you symbolic polynomical manipulation code in C?
  You miss the point.  If Vars was an enumeration type in C, an expression
like "X**4 + 2.0*x**3*y**1"...  would result in some floating point value.
Without types, it wouldn't even begin to invoke the necessary operator
overloading function calls.

>In any case your example uses features like generic instantiation and
>operator overloading that could be more directly mapped to C++. Would you
>say that C++ is more strongly typed than C?
  I assumed by "C" you really meant something newer, like "C++".  In "C"
"the only operations that you can perform on a structure are take its
address with &, and access one of its members."  (The C Programming
Language, Kernighan and Ritchie).
  In any case, I'd be curious to see how you would write the above in C++.

Re: Typing in Ada

[Peter C. Chapin]

tmoran@acm.org wrote in news:XMTuc.35148$n_6.31103@attbi_s53:

>   I assumed by "C" you really meant something newer, like "C++".  In "C"
> "the only operations that you can perform on a structure are take its
> address with &, and access one of its members."  (The C Programming
> Language, Kernighan and Ritchie).
>   In any case, I'd be curious to see how you would write the above in C++.

C++ supports operator overloading as applied to enums. It doesn't have an 
exponentiation operator, however, and you can't create new operators so that 
would create a technical inconvenience in this case. Off hand I'm not sure 
how one would create a function template in C++ that could take an 
enumeration type and print the names of the enumerators. I wouldn't want to 
say it's impossible though. In any case I'm not sure how that's related to 
the issue of strong typing.

Peter

Re: Typing in Ada

[Wes Groleau]

Dennis Lee Bieber wrote:
> On Tue, 01 Jun 2004 02:36:53 GMT, Hyman Rosen <hyrosen@mail.com>

>>limited. In a real program that does something useful, what kinds
>>of things do you want to count up to 100 but not to 101? To 200
> 
> 
> 	[snip good example]

A person's age; you may not know where to put the limit,
but you know you need to do additional checking if you
see 200.

> 	Angular measurements: 0..360 (though likely you'd want some
> floating point type with an upper bound one "step" below 360.0)

If I wanted all responses to be "normalized," I would override
the operators to make it a "modular" float.

But the point of strong typing is that you can't inadvertently
add an Age to the measure of angle AGE.

More important to me than strong typing is abstraction--the
ability to define types whose properties match what they
represent--instead of just being new names for 'int' or 'float'

When these types are numeric in nature, Ada's deriving and subtyping
mechanisms make this simple.  In C/C++/Java you have to do a lot more
work to get the same behavior.  In Java, you CAN'T get the same behavior
with reasonable syntax, since operators are banned from such types.

-- 
Wes Groleau
Alive and Well
http://freepages.religions.rootsweb.com/~wgroleau/

Re: Typing in Ada

[Niklas Holsti]

Hyman Rosen wrote:
> Nick Roberts wrote:
>  > That is to say that in most Ada
> 
>> programs it is typical to have constructions such as:
>>    type Apples is range 0..100;
>>    type Oranges is range 0..200;
> 
> 
> Is it really? The very fact that you have named these types as
> you did suggests that the appplicability of ranged types is quite
> limited. In a real program that does something useful, what kinds
> of things do you want to count up to 100 but not to 101? To 200
> but not to 201? Can you give examples from some of your real code

I'm not the original poster, but here are some examples from real code. 
I am implementing the mass memory subsystem for a satellite. The mass 
memory is divided into blocks, pages and octets. There are absolute 
address in the range 0 .. (total number of octets - 1), block numbers in 
the range 0 .. (total number of blocks - 1), page numbers likewise, 
octet offsets within a page, etc, etc. Using strong integer typing I can 
make the compiler check that I don't, by mistake, try to add a page 
number to an octet offset or do other equally senseless things.

To return to Nick Robert's example, the numbers 100 and 200 should 
either come from the requirements specification ("The program shall be 
able to count  up to 100 apples and 200 oranges...") or should appear in 
the software user manual ("The program can count up to 100 apples and 
200 oranges"). So then it is clear that the program satisfies its 
requirements (or it won't compile) and satisfies its user manual, 
whatever range Standard.Integer has on the current platform.

Niklas Holsti

Re: Typing in Ada

[Jeffrey Carter]

Peter C. Chapin wrote:

> This isn't an entirely fair comparison because in C, typedef doesn't 
> introduce a new type it simply creates a new name for an existing type. In 
> Ada, it would be more similar to using a subtype, perhaps. Something like

The number of ways in which a language allows errors to be detected at 
compilation time because of erroneous type mixing is the essence of 
strong typing. Ada is more strongly typed than Pascal because of its 
ability to define new numeric types (among other things). The ability to 
define new numeric types is a way that Ada allows the compiler to detect 
errors that C lacks. Thus, the example is a perfectly good example of 
Ada being more strongly typed than C, and a fair comparison of the 
strength of typing in the 2 languages.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Typing in Ada

[Robert I. Eachus]

Peter C. Chapin wrote:

> Yes, Ada provides ranges as distinct types without automatic conversions 
> and that's a nice feature. In theory you could get some of the same 
> benifits in C by introducing an abstract type (as a structure) to hold a 
> range. It could be done much more nicely in C++ using templates, 
> overloaded operators, and other C++ features. The reality is, though, that 
> many C (or C++) programs don't bother. Perhaps they should.
> 
> It's not clear to me how all this relates to the concept of strong typing. 
> I guess it would be helpful to have a precise definition of that term. It 
> sounds like from what we've said here that strong typing more a matter of 
> programming style than a language feature... at least where C and Ada are 
> concerned. Is that a valid conclusion?

I guess the real difference between C (or C++) and Ada is that Ada has 
many features you get "for free" at compile time if you use strong 
typing.  The most visible of these in Ada is overloading and overload 
resolution.  To extend the Apples and Oranges example, if I define

type Apple is (McIntosh, Granny_Smith, Winesap, Golden_Delicious,...);
type Orange is (Valencia, Navel, Mandarin, Seville, Bergamot...);

then

Eat(McIntosh); -- will call the Eat function for Apples, and
Eat(Navel);
  -- will call the Eat function for Oranges, and peel it first. ;-)

The most important benefit of this is that if a procedure or functions 
has a multitude of parameters some possibly with defaults, when 
programming in Ada, you don't have to "validate" the call against the 
function template.  The compiler will do that for you, and detect most 
errors.

Of course, if you write "C := A - B;" when you meant "C := B - A;"  the 
compiler probably won't catch that.  However there are cases where it 
will.  For example, Ada.Calendar defines:

   function "-" (Left : Time;   Right : Duration) return Time;
   function "-" (Left : Time;   Right : Time) return Duration;

But no operation for subtracting Time from Duration.  So Ada would catch 
a call to the first "-" with the parameters in the wrong order, but 
could not detect such an inversion if the parameters were both of type 
Time.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[Wes Groleau]

Niklas Holsti wrote:
> To return to Nick Robert's example, the numbers 100 and 200 should 
> either come from the requirements specification ("The program shall be 
> able to count  up to 100 apples and 200 oranges...") or should appear in 
> the software user manual ("The program can count up to 100 apples and 
> 200 oranges"). So then it is clear that the program satisfies its 
> requirements (or it won't compile) and satisfies its user manual, 
> whatever range Standard.Integer has on the current platform.

In a way, you are correct.  But why must we put
so much effort into preventing behavior that is
not prohibited just because it is not required?

Does the specification say ... ?
   "The program shall not tolerate apple counts higher than 100"

Did some domain expert persuade the programmers that 101 apples
was not reasonable?

In other words, when a specification says
"A count of 100 must be supported,"  the
programmers should NOT mentally rewrite it
to "Counts larger than 100 must not be supported."

-- 
Wes Groleau
Free Genealogical Lookups:
http://groleau.freeshell.org/ref/lookups.shtml

Re: Typing in Ada

[Robert I. Eachus]

Niklas Holsti wrote:

> To return to Nick Robert's example, the numbers 100 and 200 should 
> either come from the requirements specification ("The program shall be 
> able to count  up to 100 apples and 200 oranges...") or should appear in 
> the software user manual ("The program can count up to 100 apples and 
> 200 oranges"). So then it is clear that the program satisfies its 
> requirements (or it won't compile) and satisfies its user manual, 
> whatever range Standard.Integer has on the current platform.

Amen! It would be nice if one tenth the energy that has gone into the 
thread started by a misunderstanding about whether Ada was being used in 
the 7E7 project went into evangelizing simple fundamental points like 
this.  Then no matter what programming language was used, the software 
would have a much better chance of being right.  It is not a selling 
point that Ada makes it easier to trace requirements, unless the person 
you are selling to understands why requirements traceability is important.

Yes, this is an advantage of Ada.  But before you can sell Ada, you need 
people to understand why requirements documents, software development 
plans and software user manuals are important living documents that need 
to be maintained interactively during software development.

Anyone who thinks that the requirements document shouldn't be changed 
during the software development stage hasn't worked on a real project. 
There are going to be some "boilerplate" pages in requirements document. 
  But outside of those, you should expect to add a page or more of 
footnotes to each page in the original requirements document.  These 
should note "derived" requirements which are a consequence of the 
implementation chosen, clarifications of requirements, and any really 
actual changes in requirements agreed to by all parties. I've called 
them footnotes, but only because the requirements document may also be a 
legal contract.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[Robert I. Eachus]

Wes Groleau wrote:

> In a way, you are correct.  But why must we put
> so much effort into preventing behavior that is
> not prohibited just because it is not required?
> 
> Does the specification say ... ?
>   "The program shall not tolerate apple counts higher than 100"
> 
> Did some domain expert persuade the programmers that 101 apples
> was not reasonable?
> 
> In other words, when a specification says
> "A count of 100 must be supported,"  the
> programmers should NOT mentally rewrite it
> to "Counts larger than 100 must not be supported."

There are two issues here.  The first I just posted about.  If the 
requirements document is meaningful and maintained, the question about 
101 Apples needs to get asked, and answered.

Second, when the answer is that it should be read as "Count at least 100 
Apples," then the following coding "trick" is very useful:

type Required_Apples is range 0..100; -- 1..100 was pretty dodgy too...
type Apple is range 0..Required_Apples'Base'Last;

That allows software range checking to be omitted at least on the upper 
bound, and the real upper bound is set to whatever the hardware supports 
for the type chosen by the compiler for Required_Apples.

It also makes clear what the requirement being satisfied is.

Incidently you can vary this technique and make either Required_Apples a 
subtype of some integer type, or make Apples a subtype of 
Required_Apples.  There are cases when one or the other is more appropriate.


-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[tmoran]

>Second, when the answer is that it should be read as "Count at least 100
>Apples," then the following coding "trick" is very useful:
>
>type Required_Apples is range 0..100; -- 1..100 was pretty dodgy too...
>type Apple is range 0..Required_Apples'Base'Last;
>
>That allows software range checking to be omitted at least on the upper bound,
  OTOH, it means you don't know what the actual upper bound is.  More than
once during testing I've gotten something like "Constraint_Error,
offending value = 101".  If you used
type Apple_Count is range 0 .. 100;
type Orange_Count is range 0 .. 101;
then you immediately know the problem is an overflowing apple count, not
an orange count.  An "offending value = 256" would be less informative.

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in
news:Q4avc.18446$Tn6.11146@newsread1.news.pas.earthlink.net: 

>> This isn't an entirely fair comparison because in C, typedef doesn't 
>> introduce a new type it simply creates a new name for an existing type.
>> In Ada, it would be more similar to using a subtype, perhaps. Something
>> like 
> 
> The ability to 
> define new numeric types is a way that Ada allows the compiler to detect
> errors that C lacks. Thus, the example is a perfectly good example of 
> Ada being more strongly typed than C, and a fair comparison of the 
> strength of typing in the 2 languages.

I guess my point was that in C typedef does not even attempt to define a 
new type so comparing it to Ada's 'type' declaration seems unfair. For 
example if you replace the type declarations in the OP's example with 
unconstrained subtype declarations, the OP's Ada program compiles with no 
complaints just like the the example C program using typedef does.

Now in C there *is* a mechanism for creating new types... it's just that 
typedef isn't it. Thus it would be more appropriate to compare an Ada 
program that introduces a new type that is a numeric range to a C program 
that implements numeric ranges as structs. There is no doubt that the Ada 
way of creating ranged types is easier and cleaner than any kind of 
"equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
could do a much better job of emulating the Ada solution by using 
templates and overloaded operators.

In any case, the OP's example didn't seem like a good example of how Ada 
is more strongly typed than C. It is certainly true that Ada does not do 
automatic type conversions the way C does, but the OP's example doesn't 
illustrate that point. In contrast, when I think about a weakly typed 
language I think about languages like AWK, the shell scripting languages, 
or perhaps Perl... where the type of a variable shifts around depending on 
how it is used. For example:

#!/bin/bash
COUNT=1
echo "COUNT is now $COUNT"   # Treat COUNT as a string
COUNT=$(($COUNT + 1))        # Treat COUNT as a number
echo "COUNT is now $COUNT"

Peter

Re: Typing in Ada

[Marin David Condic]

Sometimes its an issue for verification. High reliability systems often 
prohibit the inclusion of any code that is not necessary to meet a 
requirement because it presents an opportunity to introduce an error 
that would not need to occur because there is no requirement to do this. 
So a similar argument can be made for restricting the number of apples 
even if the spec doesn't say Thou Shalt Not Count 101 Apples. Kind of a 
case of avoiding building the proverbial brick outhouse - don't make it 
do anything more than is required because you can't then be sure it will 
handle those cases correctly.

But then again, there are few of those sort of systems and far many more 
of the type where this would not be an issue. Then saying "At minimum, 
100 apples must be supported..." is fine and if the programmer gives you 
2**32 apples, it probably doesn't hurt anything.

MDC


Wes Groleau wrote:
> 
> In a way, you are correct.  But why must we put
> so much effort into preventing behavior that is
> not prohibited just because it is not required?
> 
> Does the specification say ... ?
>   "The program shall not tolerate apple counts higher than 100"
> 
> Did some domain expert persuade the programmers that 101 apples
> was not reasonable?
> 
> In other words, when a specification says
> "A count of 100 must be supported,"  the
> programmers should NOT mentally rewrite it
> to "Counts larger than 100 must not be supported."
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Typing in Ada

[Marin David Condic]

You may be right about structs, but making the argument that because C 
can introduce a new type that it is therefore a strongly typed language 
doesn't seem to follow. Ada won't let you assign a character to an 
integer. C will. While a typedef example may not be 100% equivalent to 
an Ada type, that doesn't cause C to be strongly typed - which was the 
original point.

I'd also observe that just because there is a secret handshake that will 
get C to complain about type compatibility doesn't mean much. Following 
that logic, an assembler program can be made to complain about type 
compatibility (at least at runtime) if you want to do enough work. The 
problem is that typedef doesn't do what one who is acustomed to Ada 
would think it should: "type" - "def" - Define a type.

MDC


Peter C. Chapin wrote:
> 
> I guess my point was that in C typedef does not even attempt to define a 
> new type so comparing it to Ada's 'type' declaration seems unfair. For 
> example if you replace the type declarations in the OP's example with 
> unconstrained subtype declarations, the OP's Ada program compiles with no 
> complaints just like the the example C program using typedef does.
> 
> Now in C there *is* a mechanism for creating new types... it's just that 
> typedef isn't it. Thus it would be more appropriate to compare an Ada 
> program that introduces a new type that is a numeric range to a C program 
> that implements numeric ranges as structs. There is no doubt that the Ada 
> way of creating ranged types is easier and cleaner than any kind of 
> "equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
> could do a much better job of emulating the Ada solution by using 
> templates and overloaded operators.
> 
> In any case, the OP's example didn't seem like a good example of how Ada 
> is more strongly typed than C. It is certainly true that Ada does not do 
> automatic type conversions the way C does, but the OP's example doesn't 
> illustrate that point. In contrast, when I think about a weakly typed 
> language I think about languages like AWK, the shell scripting languages, 
> or perhaps Perl... where the type of a variable shifts around depending on 
> how it is used. For example:
> 
> #!/bin/bash
> COUNT=1
> echo "COUNT is now $COUNT"   # Treat COUNT as a string
> COUNT=$(($COUNT + 1))        # Treat COUNT as a number
> echo "COUNT is now $COUNT"
> 
> Peter


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Typing in Ada

[Wes Groleau]

Robert I. Eachus wrote:
> Wes Groleau wrote:
> 
>> In a way, you are correct.  But why must we put
>> so much effort into preventing behavior that is
>> not prohibited just because it is not required?
> 
> There are two issues here.  The first I just posted about.  If the 
> requirements document is meaningful and maintained, the question about 
> 101 Apples needs to get asked, and answered.

I wholeheartedly agree that the code should reflect the requirements
documents whenever feasible. (Also that systems engineers should use 
abstractions and stop filling requirements documents with implementation
details, but that's a different soapbox!)

And your "trick" which

> ... allows software range checking to be omitted at least on the upper 
> bound, and the real upper bound is set to whatever the hardware supports 
> for the type chosen by the compiler for Required_Apples.

is excellent and definitely

... makes clear what the requirement being satisfied is.

My side rant was inspired by the number of times I have
fixed defects and/or supported "new" requirements by stripping
out code which had no value beyond preventing the program from
exceeding its perceived requirements.  :-)

-- 
Wes Groleau

    A UNIX signature isn't a return address, it's the ASCII equivalent
    of a black velvet clown painting.  It's a rectangle of carets
    surrounding a quote from a literary giant of weeniedom like
    Heinlein or Dr. Who.
                                 -- Chris Maeda

    Ha, ha, Dr. ..... Who's Chris Maeda?
                                 -- Wes Groleau

Re: Typing in Ada

[Hyman Rosen]

Robert I. Eachus wrote:
> type Apple is (McIntosh, Granny_Smith, Winesap, Golden_Delicious,...);
> type Orange is (Valencia, Navel, Mandarin, Seville, Bergamot...);
> Eat(McIntosh);
> Eat(Navel);

Actually, if you emulate Ada's notion that enumeration literals
are functions which return their value, this carries over directly
into C++:

enum Apple_e { };
typedef Apple_e Apple(Apple_e);
Apple McIntosh, Granny_Smith, Winesap, Golden_Delicious, Hybrid;
void Eat(Apple);
void EatApple(Apple);

enum Orange_e { };
typedef Orange_e Orange(Orange_e);
Orange Valencia, Navel, Mandarin, Seville, Bergamot, Hybrid;
void Eat(Orange);
void EatOrange(Orange);

int main()
{
     Eat(McIntosh);
     Eat(Navel);
     EatApple(Hybrid);
     EatOrange(Hybrid);
}

Re: Typing in Ada

[Dave Thompson]

On Tue, 01 Jun 2004 01:09:41 GMT, "Peter C. Chapin"
<pchapin@sover.net> wrote:

> tmoran@acm.org wrote in news:_KOuc.24339$IB.6225@attbi_s04:
> 
> >   How would you do in C the equivalent of
<snip>
> Are you asking me to show you symbolic polynomical manipulation code in C? 
> I don't understand how that bears on the question of how strongly typed C 
> is. In any case your example uses features like generic instantiation and 
> operator overloading that could be more directly mapped to C++. Would you 
> say that C++ is more strongly typed than C?
> 
Slightly. In C enum types simply are integer types; in C++ they are
distinct, though it will silently convert an enum _to_ an integer (not
the reverse). And C++ makes character literals type char instead of
type int, so overloading on that type has some hope of being usable. 
(Although char still is, and promotes as, an integer type.)

And it does not allow silent conversions _from_ pointer-to-void (which
is the moral equivalent of System.Address) to other (data) pointers.
(This is actually a specific case of not allowing conversions "down"
the class hierarchy, which in general does not apply to C.)

And finally, though people don't always think of it as typing, C++
requires the "new" style declaration of routines/methods with
parameters specified so calls, and pointers-to-function (and pmfs) if
used, can be fully checked*; C supports this but also allows the old
K&R1 FORTRANish function-of-you-must-know-the-args. For that matter,
C++ and C99, unlike C89 and earlier, no longer have implicit
declarations of functions, as taking unspecified arguments and
returning int; this isn't really a typing issue, as an implicitly
declared function actually has the same type, and gets the same
(limited) checking, as an equivalent explicit declaration, but lack of
a visible, checkable, and modifiable declaration makes it seem so.

* except for varargs -- and C++ default arguments and overloading
allow better alternatives in many cases to varargs.

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[Dave Thompson]

On Tue, 01 Jun 2004 11:26:30 GMT, "Peter C. Chapin"
<pchapin@sover.net> wrote:

> tmoran@acm.org wrote in news:XMTuc.35148$n_6.31103@attbi_s53:
> 
> >   I assumed by "C" you really meant something newer, like "C++".  In "C"
> > "the only operations that you can perform on a structure are take its
> > address with &, and access one of its members."  (The C Programming
> > Language, Kernighan and Ritchie).

If you are reading the first edition aka "K&R1", that is out of date.
Since the early '80s and in particular in C89 and later, you can also
assign a (whole, fixed size) struct, and as a logical consequence pass
it as an argument (all arguments are by value in C) or return it as a
function value. But yes only in C++ can you overload on struct types,
or indeed any other.

> >   In any case, I'd be curious to see how you would write the above in C++.
> 
Sorry I'm only online intermittently so I couldn't download the
previous reference in reasonable time. I'm responding on the
assumption it manipulates and displays (representations of)
polynomials in something like the obviously (to me) implied way.

> C++ supports operator overloading as applied to enums. It doesn't have an 
> exponentiation operator, however, and you can't create new operators so that 
> would create a technical inconvenience in this case. Off hand I'm not sure 

You could overload enum varid ^ int exponent, since there would be no
use here for the usual C and C++ meaning as exclusive-or, but it has
rather low precedence with the other bitwise operators (which can't be
changed) hence couldn't be used as conveniently.

> how one would create a function template in C++ that could take an 
> enumeration type and print the names of the enumerators. I wouldn't want to 
> say it's impossible though. In any case I'm not sure how that's related to 
> the issue of strong typing.
> 
You can't; enum names are solely compile time in both C and C++,
except for nonstandard and (very) platform-dependent debugging. What
you can do is a preprocessor trick, something like:

#define Vars_List Var1(X) Var1(Y) Var1(Z)
#define Var1(id) id , /* in enum definition */
enum Vars { Vars_List }; /* note trailing comma allowed in C99, 
in unextended C89 have to hack this slightly or add a dummy name, 
which can actually be useful anyway for idiomatic half-open [0,N) */
#undef Var1
#define Var1(id) # id , /* in table of names */
const char * Vars_names [] = { Vars_List };
#undef Var1
/* now Y=1 and Vars_names[Y] is the string "Y" etc. */

Alternatively, instead of actual enum values, you could in C++ define
and use instances of a class type that collapse into the needed data:

class Term { 
  int varid, expon; double factor;
public:
  /*ctor*/ Term (int varid) 
    : varid (varid), expon (1), factor (1.0) { }
  /* could use a Freevar method that doublechecks varid is in the 
    valid range, known at startup but not compiletime; but if this 
    is made private and the Freevar method a friend, 
    invalid calls are prevented at compile time barring cheating */

  Term& operator^= (int expon) 
    { this->expon *= expon; return *this; }
  Term  operator^  (int expon) 
    { Term that (*this); return that ^= expon; }
  Term& operator*= (double factor) 
    { this->factor *= factor; return *this; }
  Term  operator*  (double factor) 
    { Term that (*this); return that *= factor; }

};

class Freevar {
/*private:*/
typedef std::vector <const char *> var_names_t;
static var_names_t var_names;
  int varid;
public:
  /*ctor*/ Freevar (const char *this_name) 
    /* save name-string and "return" subscript thereto */
    { 
      var_names_t::iterator new_item =
        var_names.insert (var_names.end(), this_name); 
      this->varid = new_item - var_names.begin();
    }
static const char * get_name (int id) 
    { return var_names [id]; /* or safer .at(id) */ }
  /*conversion*/ operator Term () const 
    { return Term (this->varid); }
  /*converting*/ Term operator^ (int expon) const 
    { return Term (*this) ^ expon; }
};
Freevar::var_names_t Freevar::var_names; /* "initialize" */
const Freevar X ("X"); /* gets id 0 */
const Freevar Y ("Y"); /* gets id 1 */
const Freevar Z ("Z"); /* gets id 2 */
/* these particular id values guaranteed only if all (static) 
  definitions in same source file/module; if in separate modules 
  they will be unpredictable but unique, which is enough */

Now Y ^ 3 yields a Term containing an exponent of 3 for id 1, and say
Term::output can use Freevar::get_name (1) to get "Y".

If you want to do this for multiple "enums" I think you can templatize
it but I haven't worked that one out in detail.

Or as a real hack you could make the values (singleton instances of)
classes that inherit with at least one virtual method, thereby
providing RTTI (Run-Time Type Information) whose implementation
dependent values you then decode somehow. Yuck.

It probably should (but won't) go without saying that this is more
work and less simple than built-in compiler support as in Ada.

Additional minor point: in C you can't really return a string as a
function value. You must either store into a caller-provided buffer;
return a pointer to static space (not threadsafe and dubious if used
multiple times); or return a pointer to allocated space (caller must
free). In C++ you can return a std::string; (in practice though not
formally required) this is really a pointer to heap space, but is
managed automatically.

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[Dave Thompson]

On Wed, 02 Jun 2004 11:38:04 GMT, Marin David Condic
<nobody@noplace.com> wrote:
<snip>
> I'd also observe that just because there is a secret handshake that will 
> get C to complain about type compatibility doesn't mean much. Following 
> that logic, an assembler program can be made to complain about type 
> compatibility (at least at runtime) if you want to do enough work. The 
> problem is that typedef doesn't do what one who is acustomed to Ada 
> would think it should: "type" - "def" - Define a type.
> 
One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
the 'struct' keyword -- which unlike 'typedef' does create a distinct
type as far as the C compiler is concerned -- should be read as an
acronym "STRange spelling for User Constructed Type". :-)

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[James Rogers]

Dave Thompson <david.thompson1@worldnet.att.net> wrote in
news:gn12d0pk7e6hhmhr6k87hcj4olebou5hel@4ax.com: 

> One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
> the 'struct' keyword -- which unlike 'typedef' does create a distinct
> type as far as the C compiler is concerned -- should be read as an
> acronym "STRange spelling for User Constructed Type". :-)

Yes, a C struct is the means for creating a user defined type.
It is similar to an Ada record, without all the representation
control or the possibility of discriminants. 

One important difference between Ada records and C structs is
in the creation of incomplete types. A C compiler allows the
creation of incomplete types under the assumption that the
type will be completed through the linking process, while an
Ada compiler must have all types completed at compile time.

Jim Rogers

Re: Typing in Ada

[Hyman Rosen]

James Rogers wrote:
> One important difference between Ada records and C structs is
> in the creation of incomplete types. A C compiler allows the
> creation of incomplete types under the assumption that the
> type will be completed through the linking process, while an
> Ada compiler must have all types completed at compile time.

No, incomplete types in C have nothing to do with linking.
Incomplete types are there for the same reason as in any
other language, so that mutually recursive types may be
declared. Eg.,
     struct A;
     struct B { struct A *my_A; int x; };
     struct A { struct B *my_B; int y; };
For this mutual recursion to be possible, C and C++ must
then identify the places where incomplete types may be used,
such as in declarations of pointers to them, or as function
parameters - basically those places where knowing the innards
of the type is unnecessary.

It is true in C or C++ that if you never have a context in
which you need the complete type, you need not supply it,
even at link time.

Re: Typing in Ada

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in 
news:1087475285.166449@master.nyc.kbcfp.com:

> No, incomplete types in C have nothing to do with linking.
> Incomplete types are there for the same reason as in any
> other language, so that mutually recursive types may be
> declared. Eg.,
>      struct A;
>      struct B { struct A *my_A; int x; };
>      struct A { struct B *my_B; int y; };
> For this mutual recursion to be possible, C and C++ must
> then identify the places where incomplete types may be used,
> such as in declarations of pointers to them, or as function
> parameters - basically those places where knowing the innards
> of the type is unnecessary.
> 
> It is true in C or C++ that if you never have a context in
> which you need the complete type, you need not supply it,
> even at link time.

Perhaps I misspoke. I did not mean that C reserves incomplete
types for link time. I meant to say that the compiler does not
require completion of incomplete types. This effect allows a
C program to define an incomplete type in the global area of
one file and complete the type in another file. The compiler
never knows of the completion, while the linker might.

I agree that the most common use of incomplete types is the
same in C as in Ada; for recursive or self-referential types.
One common example is a singly linked list, where one of the
node data elements is a reference or pointer to the next node.

A common Ada implementation approach is:

package Single_List is
   type List is private
   procedure add(Item : in Item_Type; To : in out List);
   procedure get(Item : out Item_Type; From : in out List);
   function Is_Empty(The_List : List) return Boolean;
private
   type Node;
   type List is Access Node;
   Type Node is record
     Element : Item_Type;
     Next    : List := Null;
   end record;
end Single_List;

The Ada difference is that all incomplete types must be
completed in the same compilation unit.

Jim Rogers

Re: Typing in Ada

[Nick Roberts]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns950BB3B4DBFE6jimmaureenrogers@204.127.36.1...

> ...
> The Ada difference is that all incomplete types must be
> completed in the same compilation unit.

In fact, this restriction is likely be lifted (in a very restricted way ;-)
in the new revision of the Ada language. It has proved to be too
inconvenient.

Whether implementations will join up the dots at (traditional) link time, or
at some pre-linking stage instead, is yet to be seen. I think the latter is
more likely.

-- 
Nick Roberts