Re: Inheritance and Polymorphism in Ada !!

Re: Inheritance and Polymorphism in Ada !!

[Lutz Donnerhacke]

* Chango Cho wrote:
>Do they exist in Ada?

Yes. Look for tagged types and class wide programming in the RM.
   http://www.adahome.com/rm95/rm9x-03-09.html
   http://www.adahome.com/rm95/rm9x-03-09-02.html

Futhermore look at the Rationale:
 Intro:
   http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p1-2.html#1
   http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p1-2.html#2
   http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p1-2.html#3
 Deeper look:
   http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p2-4.html

Re: Inheritance and Polymorphism in Ada !!

[Lutz Donnerhacke]

* Andreas Winckler wrote:
>14 begin
>15     pointer := new type_b;
>16     type_b(pointer.all).second_field := 1;
>17 end inheritance_polymorphism;
>
>See line 16, the type of the referenced object must be known in advance.
>With "pointer.second_field :=1" the compiler fails. It seems that the
>strong typing restricts the features of polyormism in Ada. Any comments?
>Am I wrong?

Yep. To access data, please provide functions. They dispach as required for
polymorphism.

Re: Inheritance and Polymorphism in Ada !!

[Ted Dennison]

In article <7u64k3$l1d$1@hiline.shinbiro.com>,
  "Chango Cho" <compusm@chollian.net> wrote:
>
>     Do they exist in Ada?

Yes, they exist in both Ada83 and Ada 95. Ada 95 also has extension and
runtime polymorphism.


>     thanks in advance

You're welcome.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[tmoran]

> 1  procedure inheritance_polymorphism is
> 2
> 3  type type_a is tagged record
> 4           first_field : integer;
> 5       end record;
> 6
> 7  type type_b is new type_a with record
> 8           second_field : integer;
> 9       end record;
> 10
> 11 type pointer_type is access all type_a'class;
> 12 pointer      : pointer_type;
> 13
> 14 begin
> 15     pointer := new type_b;
> 16a    type_b(pointer.all).second_field := 1;
> 16b    pointer.second_field := 1;
> 17 end inheritance_polymorphism;
> See line 16, the type of the referenced object must be known in advance.
> With "pointer.second_field :=1" the compiler fails. It seems that the
> strong typing restricts the features of polyormism in Ada. Any comments?

  Suppose you insert, just after line 15,
    if phase_of_moon = full then pointer := new type_a;end if;
Then at run time the code would have to check that whatever "pointer"
was currently pointing to, contained a field named "second_field".
Further, since perhaps type_b's second_field might not be integer, eg
     type type_b is new type_a with record
              second_field : character;
          end record;
it would have to check that the particular "second_field" was an
integer before it could assign a "1" to it.

  Suppose "pointer.second_field := 1;" is in a subroutine called from
someplace where "pointer" points to some type_d, which might or might
not have a field named "second_field", which might or might not be an
integer.  This isn't known at the time of compiling
"pointer.second_field := 1;" so the generated code would need to call
some routine associated with the tag on pointer.all and say "I'd like
to store an integer with value 1 in a field named "second_field'.
Please either do that or raise some appropriate exception."

  Would you really want all that?

> See line 16, the type of the referenced object must be known in advance.
  No.  If you change line 11 to
> 11 type pointer_type is access all type_b'class;
  then "pointer.second_field :=1;" compiles just fine, since it's
clear that anything the pointer might point to, does indeed have
an integer "second_field".

> With "pointer.second_field :=1" the compiler fails.
 No, the compiler succeeds in detecting an error - before run time.

Re: Inheritance and Polymorphism in Ada !!

[tmoran]

Oops,
> Further, since perhaps type_b's second_field might not be integer, eg
>      type type_b is new type_a with record
>               second_field : character;
should have said "since there might be a type_c with a second_field
that is not an integer" ...

Re: Inheritance and Polymorphism in Ada !!

[Matthew Heaney]

In article <3806DC34.1513E8B1@frqnet.de> , Andreas Winckler 
<andreas.winckler@frqnet.de>  wrote:

> Yes, but in my opinion polymorphism is kind of restricted in Ada.

No, there is no restriction.


> See line 16, the type of the referenced object must be known in advance.
> With "pointer.second_field :=1" the compiler fails. It seems that the
> strong typing restricts the features of polyormism in Ada. Any comments?

"Class-wide" programming means programming against all the types in the
class.  When you manipulate an object whose type is Type_A'Class, then
what you're saying is you only care about those attributes that are
common to ALL types.

The field "second_field" is not common to all types in the class
Type_A'Class, so it doesn't make any sense to complain you can't
automatically see it.  If you're interested in that field, then
obviously you want an object whose type is Type_B'Class, or just Type_B.


> Am I wrong?

Yes.


> However, when it comes to real_world_applications like the air traffic
> control systems I do, polymorphism and dynamic memory allocation is a
> DO_NOT anyway.

Yes, it's true that dynamic memory allocation isn't allowed, but Ada was
designed to that you don't need dynamic memory allocation.

There was no reason for you to put the object on the heap.  You could
have said just as easily:

  Object : Type_A'Class := Type_B'(1, 2);

No heap required.

Of course, you don't have to declare you're objects as class-wide,
meaning dynamic dispatch does *not* occur, which means you really *can*
use tagged types in safety-critical systems.  For example:

  Object : Type_B := (1, 2);


--
Why stop at evolution and cosmology, though? Let's make sure that the
schoolkids of Kansas get a really first-rate education by loosening up
the teaching standards for other so-called scientific ideas that are,
after all, just theories. The atomic theory, for example. The theory of
relativity. Heck, the Copernican theory--do we really know that the
universe doesn't revolve around the earth?

John Rennie, Scientific American, Oct 1999

Re: Inheritance and Polymorphism in Ada !!

[Matthew Heaney]

In article <7u7o36$tv8$1@nntp6.atl.mindspring.net> , Richard D Riehle 
<laoXhai@ix.netcom.com>  wrote:

> Alternatively, the declare block could (many say _should_) be promoted to a
> subprogram call.

Whoever says "should" is wrong.

The purpose of a declare block is to localize the declaration of
objects, as your example illustrated.

The purpose of a subprogram is to abstract away algorithmic complexity.

These are two completely different things, and there should be no reason
why they are confused.

Matt

--
Help keep evolution in the science classroom and religion out: become a
member of the National Center for Science Education.

<http://www.natcenscied.org/>

Inheritance and Polymorphism in Ada !!

[Chango Cho]

    Do they exist in Ada?
    thanks in advance

    Chang

Re: Inheritance and Polymorphism in Ada !!

[Andreas Winckler]

Chango Cho schrieb:
> 
>     Do they exist in Ada?

Yes, but in my opinion polymorphism is kind of restricted in Ada.

See this example:

1  procedure inheritance_polymorphism is
2
3  type type_a is tagged record
4           first_field	: integer;
5       end record;
6
7  type type_b is new type_a with record
8           second_field : integer;
9       end record;
10
11 type pointer_type is access all type_a'class;
12 pointer	: pointer_type;
13
14 begin
15     pointer := new type_b;
16     type_b(pointer.all).second_field := 1;
17 end inheritance_polymorphism;

See line 16, the type of the referenced object must be known in advance.
With "pointer.second_field :=1" the compiler fails. It seems that the
strong typing restricts the features of polyormism in Ada. Any comments?
Am I wrong?

However, when it comes to real_world_applications like the air traffic
control systems I do, polymorphism and dynamic memory allocation is a
DO_NOT anyway.


Greetings,

AW
-- 
=========================================================
Andreas Winckler
Dipl.-Ing.
Software engineering
FREQUENTIS Network Systems GmbH
Tel: (+49) (7541) 282 - 462  Fax: (+49) (7541) 282 - 299
http://www.frqnet.de

Re: Inheritance and Polymorphism in Ada !!

[Stephane Barbey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]


Andreas Winckler <andreas.winckler@frqnet.de> wrote in message
news:3806DC34.1513E8B1@frqnet.de...
> See line 16, the type of the referenced object must be known in advance.
> With "pointer.second_field :=1" the compiler fails. It seems that the
> strong typing restricts the features of polyormism in Ada. Any comments?

This would be illegal in all other OO languages I know of.
For instance, in Java:

public class A {
    int first_field;
}

public class B extends A {
      int second_field;
}

import A;
import B;
public class inheritance_polymorphism {

  public static void main(String[] args) {
    A pointer = new B();

    pointer.second_field = 1;              /* illegal */
    ((B)pointer).second_field = 1;      /* legal */
  }

}

-St�phane


----
Stephane Barbey, PhD   phone: +41(31)828.92.17
Paranor AG             fax:   +41(31)828.92.99
3046 Wahlendorf            stephane@paranor.ch
Switzerland      http://lglwww.epfl.ch/~barbey

Re: Inheritance and Polymorphism in Ada !!

[Richard D Riehle]

In article <3806DC34.1513E8B1@frqnet.de>,
	Andreas Winckler <andreas.winckler@frqnet.de> wrote:

>
>Chango Cho schrieb:
>> 
>>     Do they exist in Ada?
>
>Yes, but in my opinion polymorphism is kind of restricted in Ada.

There are lots of alternatives to dynamic polymorphism in Ada.  Here is
a simple package with three simplified examples.

package Thingamabobs is                              --  1
  type Gadget is tagged private;                     --  2
  type Gadget_Pointer is access all Gadget'Class;    --  3
  procedure Display (G : in Gadget);                 --  4
  type Doohickey is new Gadget with private;         --  5 
  procedure Display (G : in Doohickey);              --  6
  function  Get return Gadget'Class;                 --  7
private                                              --  8
  type Gadget is tagged record                       --  9
     Is_On : Boolean := False;                       -- 10
  end record;                                        -- 11
  type Doohickey is new Gadget with record           -- 12
     Spinning : Boolean := False;                    -- 13
  end record;                                        -- 14
end Thingamabobs;                                    -- 15

with the following little test program,

with Thingamabobs;                                   --  1
with Ada.Text_IO;                                    --  2
with Ada.Integer_Text_IO;                            --  3
use  Ada;                                            --  4
procedure Test_Thingamabobs is                       --  5
  Gadget_Stuff : array (1..2) of                     --  6     
              Thingamabobs.Gadget_Pointer;           --  7
     := (1 => new Thingamabobs.Gadget,               --  8
         2 => new Thingamabobs.Doohickey);           --  9
  Index : Positive;                                  -- 10 
begin                                                -- 11
   Text_IO.Put("Enter Index Value (1/2) " );         -- 12
   Integer_Text_IO.Get(Index);                       -- 13
   Thingamabobs.Display(Gadget_Stuff(Index).all);    -- 14
end Test_Thingamabobs;                               -- 15

Another way to approach this is to declare the classwide type within
a declare block and constrain it with a function call,

with Thingamabobs;                                   --  1
procedure Get_Thingamabobs is                        --  2
begin                                                --  3
   declare                                           --  4 
      Gadget_Stuff : Thingamabobs.Gadget'Class       --  5
                   := Thingamabobs.Get;              --  6
   begin                                             --  7
      Thingamabobs.Display(Gadget_Stuff);            --  8
   end;                                              --  9
end Get_Thingamabobs;                                -- 10

where the declare block could be placed inside a loop.  Alternatively,
the declare block could (many say _should_) be promoted to a subprogram
call.  Finally, we have a really shortened example that illustrates 
some of the power associated with a classwide function and a dispatching
call,

with Thingamabobs;                                   --  1
procedure Abbreviated_Get_Thingamabobs is            --  2
begin                                                --  3
   Thingamabobs.Display(Thingamabobs.Get);           --  4
end Abbreviated_Get_Thingamabobs ;                   --  5

Typically, the Get will acquire the data from a file, a data
structure, or some other container in which the tag has been
preserved.  For example, you can create a Stream_IO file in
which the tag is persistent. 

Hope this helps,

Richard Riehle
http://www.adaworks.com

Re: Inheritance and Polymorphism in Ada !!

[Richard D Riehle]

In article <38077b65_1@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>In article <7u7o36$tv8$1@nntp6.atl.mindspring.net> , Richard D Riehle 
><laoXhai@ix.netcom.com>  wrote:
>
>> Alternatively, the declare block could (many say _should_) be promoted to
a
>> subprogram call.
>
>Whoever says "should" is wrong.

Yes, Matthew.  There are a lot of people in the industry who 
try to "should" on us.  I guess the correct response is, "Don't
should on me."   Or, perhaps, "That's a lot of Bull Should."  In
any case, I think promoting it to a subprogram is not _wrong_
either.  I think we would both agree that one must decide on the
appropriate kind of abstraction for the problem being solved.

Richard Riehle
http://www.adaworks.com

Re: Inheritance and Polymorphism in Ada !!

[Brian Rogoff]

On Mon, 18 Oct 1999, Robert A Duff wrote:
> "Matthew Heaney" <matthew_heaney@acm.org> writes:
> > Yes, it's true that dynamic memory allocation isn't allowed, but Ada was
> > designed to that you don't need dynamic memory allocation.
> > 
> > There was no reason for you to put the object on the heap.  You could
> > have said just as easily:
> > 
> >   Object : Type_A'Class := Type_B'(1, 2);
> > 
> > No heap required.
> 
> True in this case, but I think it's fair to say that if you're doing
> OOP, you will *usually* need to put some objects in the heap.  The above
> trick only works when you know the tag you want a the right time, and
> you don't want to change the tag (which you can simulate by deallocating
> and reallocating in the heap), and when you don't have heterogeneous
> data structures (eg you're not allowed to make an array of a class-wide
> type).

I agree with all of this, but I recall a few years ago that someone :-)
posted a heap using version of Ackerman's function, directly translating 
a program Norman Cohen wrote using (full upward) closures. In this
particular program, a few tweaks and a bit of naughtiness allows us to 
write a "heapless" version, assuming that the variable sized arrays aren't 
heap allocated. I'll append this program, and refer reader's back to 
the original discussion entitled "Q: access to subprogram" from Jul '96. 
Note that even though naughty, this is Ada-95 with no GNAT extensions.

No you can't do this in general for OOP programs, but I confess that I
admire Matt's dedication to stackliness. 

-- Brian 

package body Ackermann_Computation is

    package Container is
        -- We need to put Ackermann_Row_Type in a package, so
        -- Invoke will be primitive.

        type Ackermann_Row_Type is abstract tagged limited null record;
        -- Six reserved words in a row!

        function Invoke(R: Ackermann_Row_Type; N: Natural)
                        return Natural is abstract;
        -- Invokes the closure represented by R, with parameter N.

        type Ackermann_Row_Ptr is access all Ackermann_Row_Type'Class;
   end Container;

   use Container;

   type Row_Zero_Type is new Ackermann_Row_Type with null record;

   function Invoke(R: Row_Zero_Type; N: Natural)
                   return Natural;

   function Invoke(R: Row_Zero_Type; N: Natural)
                   return Natural is
   begin
      return N + 1;
   end Invoke;

   type Successor_Row_Type is new Ackermann_Row_Type with
      record
          Pred : Ackermann_Row_Ptr;
      end record;

   -- Pred points to the predecessor row of this row.  This is analogous
   -- to the parameter F in Norman's Successor_Row function.

   function Invoke(R: Successor_Row_Type; N: Natural)
                   return Natural;

   function Invoke(R: Successor_Row_Type; N: Natural)
                   return Natural is
      Counter : Natural := N + 1;
      Result  : Natural := 1;
   begin
      while Counter /= 0 loop
         Result := Invoke(R.Pred.all, Result);
         Counter := Counter - 1;
      end loop;
      return Result;
   end Invoke;

   function Ackermann (M, N: Natural) return Natural is
      Row_Zero : aliased Row_Zero_Type;  -- R[0]
      Row      : array (1 .. M) of aliased Successor_Row_Type;
      Row_Ptr  : Ackermann_Row_Ptr := Row_Zero'Unchecked_Access;
   begin
       if M = 0 then
           return N+1;
       end if;

       for I in 1 .. M loop
           Row(I).Pred := Row_Ptr;
           Row_Ptr     := Row(I)'Unchecked_Access;
           -- Compute R[1] from R[0], R[2] from R[1], ...
       end loop;
       return Invoke(Row(M), N);  -- i.e., R[m](n)
   end Ackermann;

end Ackermann_Computation;

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article <38077b65_1@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
> The purpose of a declare block is to localize the declaration
> of objects, as your example illustrated.

too narrow a view, there are other reasons: conveniently
encapsulate and name a chunk of code used only once, narrow
down an exception scope, etc etc.

> The purpose of a subprogram is to abstract away algorithmic
> complexity.

too narrow a view, there are other reasons: allow recursion,
name a chunk of code, take advantage of the return semantics,
etc.

> These are two completely different things, and there should be
> no reason why they are confused.

Well if you take a simplistic and narrow view, you perhaps can
avoid the confusion, but in fact there is a definite overlap for
the case of a chunk of non-recursive code that is called just
once. This might be a declare block, it might be a procedure,
it depends, sometimes one is better, sometimes the other.




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> In article <7u7o36$tv8$1@nntp6.atl.mindspring.net> , Richard D Riehle 
> <laoXhai@ix.netcom.com>  wrote:
> 
> > Alternatively, the declare block could (many say _should_) be promoted to a
> > subprogram call.
> 
> Whoever says "should" is wrong.

Whoever says "wrong" about matters that are clearly matters of opinion,
such as this stylistic issue, is wrong.  ;-) How about, "I disagree
with..."  or "It's a bad idea to ..." or "You'll be sorry if..."?  I
would understand you better if you reserved "wrong" to point out factual
mistakes.

Anyway, I agree that you shouldn't always turn block statements into
procedures.

My main complaint about block statements is that they're verbose: they
introduce three extra lines of code which don't impart any useful
information to the reader of the code.  Why can't I just declare a local
variable in any statement list?  And they introduce an extra (bogus)
level of indentation.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

Andreas Winckler <andreas.winckler@frqnet.de> writes:

> Yes, but in my opinion polymorphism is kind of restricted in Ada.

Compared to which language?  Polmorphism in Ada works pretty much the
same as in Java, C++, Eiffel, &c, roughly speaking -- although the
syntax is rather different.  I suppose you could argue that Ada's
polymorphism is more restrictive (for good reason!) than Smalltalk's,
but your example wouldn't be allowed in Smalltalk anyway, so I don't
know what you're comparing Ada against.

> See this example:
> 
> 1  procedure inheritance_polymorphism is
> 2
> 3  type type_a is tagged record
> 4           first_field	: integer;
> 5       end record;
> 6
> 7  type type_b is new type_a with record
> 8           second_field : integer;
> 9       end record;
> 10
> 11 type pointer_type is access all type_a'class;
> 12 pointer	: pointer_type;
> 13
> 14 begin
> 15     pointer := new type_b;
> 16     type_b(pointer.all).second_field := 1;
> 17 end inheritance_polymorphism;
> 
> See line 16, the type of the referenced object must be known in advance.
> With "pointer.second_field :=1" the compiler fails. It seems that the
> strong typing restricts the features of polyormism in Ada. Any comments?
> Am I wrong?

Hard to tell -- you just said it's "restrictive", but you didn't say
compared to *what*.  It seems clear to me that you shouldn't *want* the
above example to be legal.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> Yes, it's true that dynamic memory allocation isn't allowed, but Ada was
> designed to that you don't need dynamic memory allocation.
> 
> There was no reason for you to put the object on the heap.  You could
> have said just as easily:
> 
>   Object : Type_A'Class := Type_B'(1, 2);
> 
> No heap required.

True in this case, but I think it's fair to say that if you're doing
OOP, you will *usually* need to put some objects in the heap.  The above
trick only works when you know the tag you want a the right time, and
you don't want to change the tag (which you can simulate by deallocating
and reallocating in the heap), and when you don't have heterogeneous
data structures (eg you're not allowed to make an array of a class-wide
type).

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article <wccwvsk1ul4.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> And they introduce an extra (bogus)
> level of indentation.


I like the extra level of indentation, it shows clearly the
scope of the variables that are introduced.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I like the extra level of indentation, it shows clearly the
> scope of the variables that are introduced.

Well, I suppose this is a matter of taste, to some extent.

But why do you dislike this:

    for I in Some_String'Range loop
        X: Character renames Some_String(I); -- Not legal Ada.
        X := To_Lower(X);
        ... maybe other uses of X ...
    end loop;

?

It seems clear enough (to me) that the scope of X is the body of the
loop.  There's *already* a level of indentation indicating that fact, so
why do you like to have an *extra* one?

Another example: I often want to add a statement at the beginning of a
procedure.  I want it to happen before anything else.  Maybe a debugging
print-out, for example.  Or maybe some sort of checking on the input
parameters, like an assertion.  If I put it after the "begin", I will
miss all the elaborations.  So I have to surround the whole procedure
with a block statement, and *then* add my new statement.  I wouldn't
mind adding the verbosity if it helped the reader, but I think it does
just the opposite.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Inheritance and Polymorphism in Ada !!

[Simon Wright]

Robert A Duff <bobduff@world.std.com> writes:

> Another example: I often want to add a statement at the beginning of a
> procedure.  I want it to happen before anything else.  Maybe a debugging
> print-out, for example.  Or maybe some sort of checking on the input
> parameters, like an assertion.  If I put it after the "begin", I will
> miss all the elaborations.  So I have to surround the whole procedure
> with a block statement, and *then* add my new statement.  I wouldn't
> mind adding the verbosity if it helped the reader, but I think it does
> just the opposite.

If you're using GNAT, you can use pragma Debug and pragma Assert ..

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

Simon Wright <simon@pogner.demon.co.uk> writes:

> If you're using GNAT, you can use pragma Debug and pragma Assert ..

I work for AverStar, which makes a competing Ada product.  ;-)
We have a pragma Assert, but no pragma Debug.

Anyway, pragma Debug is no good for things *other* than debugging
print-outs (which you might turn off!).

- Bob

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article <wcchfjmx7y5.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > I like the extra level of indentation, it shows clearly the
> > scope of the variables that are introduced.
>
> Well, I suppose this is a matter of taste, to some extent.
>
> But why do you dislike this:
>
>     for I in Some_String'Range loop
>         X: Character renames Some_String(I); -- Not legal Ada.
>         X := To_Lower(X);
>         ... maybe other uses of X ...
>     end loop;

As you say it is a matter of taste, I prefer to see declarations
clearly marked off and separated from statements, this
separation helps *this* reader :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[Paul Duquennoy]

Robert A Duff a *crit :
> Another example: I often want to add a statement at the beginning of a
> procedure.  I want it to happen before anything else.  Maybe a debugging
> print-out, for example.  Or maybe some sort of checking on the input
> parameters, like an assertion.  If I put it after the "begin", I will
> miss all the elaborations.  So I have to surround the whole procedure
> with a block statement, and *then* add my new statement.  I wouldn't
> mind adding the verbosity if it helped the reader, but I think it does
> just the opposite.

For such debug printouts before any declarations, I often use a function :

   function Debug_Printout (Mess : in String) return boolean is
   begin
	Ada.Text_Io.Put_Line (Mess);
	return true;
   end Debug_Printout;

Then I can insert it in my procedure :

   procedure X (...) is
      Dummy_1 : constant Boolean := Debug_Printout ("Start of declarations");

      .....

It prooved usefull to track exceptions occuring during initialisations.

Paul

Re: Inheritance and Polymorphism in Ada !!

[Matthew Heaney]

In article <wccwvsk1ul4.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

> My main complaint about block statements is that they're verbose: they
> introduce three extra lines of code which don't impart any useful
> information to the reader of the code.  Why can't I just declare a local
> variable in any statement list?  And they introduce an extra (bogus)
> level of indentation.

I agree completely.  Especially as declarations that include an
initialization expression begin to blur the difference between a
declaration and an (executable) statement.

I think you can do that in C++, just declare an object anywhere you
want.  Very nice.

--
The new standards [for science curricula in Kansas] do not forbid the
teaching of evolution, but the subject will no longer be included in
statewide tests for evaluating students--a virtual guarantee, given the
realities of education, that this central concept of biology will be
diluted or eliminated, thus reducing courses to something like chemistry
without the periodic table, or American history without Lincoln.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Inheritance and Polymorphism in Ada !!

[Richard D Riehle]

>In article <38077b65_1@news1.prserv.net>,
>  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
>> The purpose of a declare block is to localize the declaration
>> of objects, as your example illustrated.

I remembered reading a short discussion of the Algol
equivalent of declare blocks in Dijkstra's oldie but goodie, 
A Discipline of Computer Programming.  So I pulled my
dog-eared copy from a nearby bookshelf to re-read it.
Read chapter 10 for a well-reasoned criticism of this notion.  

Not very much has changed in the Ada declare block.  All the 
same problems exist that we had with Algol. It is quite 
wonderful that we are still arguing the same issues that we 
were arguing about in 1976 when Dijkstra's book was published.

Richard Riehle
http://www.adaworks.com

Re: Inheritance and Polymorphism in Ada !!

[Brian Rogoff]

On Sun, 24 Oct 1999, Robert Dewar wrote:
> In article <7uqvb1$2m4$1@nntp3.atl.mindspring.net>,
>   Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> 
> > I remembered reading a short discussion of the Algol
> > equivalent of declare blocks in Dijkstra's oldie but goodie,
> > A Discipline of Computer Programming.  So I pulled my
> > dog-eared copy from a nearby bookshelf to re-read it.
> > Read chapter 10 for a well-reasoned criticism of this notion.
> >
> > Not very much has changed in the Ada declare block.  All the
> > same problems exist that we had with Algol. It is quite
> > wonderful that we are still arguing the same issues that we
> > were arguing about in 1976 when Dijkstra's book was published.
> 
> Yes, indeed, this is an old argument :-)
> 
> My feeling is that people do not use declare blocks NEARLY
> often enough. In a language like C or Ada (unlike say COBOL
> which has a light syntax for local procedures, sorry, can't
> help getting in that dig :-) it is impractical to introduce
> a new procedure every time we have a local variable. For
> example, if we say
> 
>   t := a;
>   a := b;
>   b := t;

In Python 

	a,b = b,a

Far more readable to me than anything C or Ada has to offer. Sorry, I
couldn't resist either!

> And then of course in Ada, the paradigm:
> 
>    read (N);
>    declare
>       x : matrix (1 .. N, 1 .. N);
>    ...
> 
> is very valuable. I really think the notion of declare blocks
> is a very important one. Algol-60 of course had both nested
> procedures and nested blocks. It is interesting that there
> have been three threads of development of these ideas:
> 
> Omit nested procedures, keep nested blocks (C, C++)
> Omit nested blocks, keep nested procedures (Pascal)
> Keep both (PL/1, Ada)
> 
> I far prefer the third approach.

Agreed.

> Note that the issue of heaviness of syntax (and whether you
> need a marker between declarations and statements, which is
> the point Bob Duff has made) is quite orthogonal to the
> fundamental point that nested blocks are very valuable.

I think Bob Duff's point was a good one. The renaming syntax is heavy.
That's part of the reason someone suggested alternate devices for 
places where renaming might be used. 

-- Brian

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article <7uqvb1$2m4$1@nntp3.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:

> I remembered reading a short discussion of the Algol
> equivalent of declare blocks in Dijkstra's oldie but goodie,
> A Discipline of Computer Programming.  So I pulled my
> dog-eared copy from a nearby bookshelf to re-read it.
> Read chapter 10 for a well-reasoned criticism of this notion.
>
> Not very much has changed in the Ada declare block.  All the
> same problems exist that we had with Algol. It is quite
> wonderful that we are still arguing the same issues that we
> were arguing about in 1976 when Dijkstra's book was published.

Yes, indeed, this is an old argument :-)

My feeling is that people do not use declare blocks NEARLY
often enough. In a language like C or Ada (unlike say COBOL
which has a light syntax for local procedures, sorry, can't
help getting in that dig :-) it is impractical to introduce
a new procedure every time we have a local variable. For
example, if we say

  t := a;
  a := b;
  b := t;

to do an exchange, it is usually unhappily heavy to introduce
a special local exchange procedure that is used once (even
worse, for those who can't bear to nest procedures, or, horrors
are not allowed to do so by the language they are using, a
global procedure).

On the other hand, we far prefer

   declare
      t : constant integer := a;
   begin
      a := b;
      b := t;
   end;

because it tells the reader that it is safe to forget the
value of t, since it is never referenced again, whereas the
original set of three assignments happened to leave t set
to a value which could be referenced later (with no indication
of whether or not it actually is so referenced).

And then of course in Ada, the paradigm:

   read (N);
   declare
      x : matrix (1 .. N, 1 .. N);
   ...

is very valuable. I really think the notion of declare blocks
is a very important one. Algol-60 of course had both nested
procedures and nested blocks. It is interesting that there
have been three threads of development of these ideas:

Omit nested procedures, keep nested blocks (C, C++)
Omit nested blocks, keep nested procedures (Pascal)
Keep both (PL/1, Ada)

I far prefer the third approach.

Note that the issue of heaviness of syntax (and whether you
need a marker between declarations and statements, which is
the point Bob Duff has made) is quite orthogonal to the
fundamental point that nested blocks are very valuable.

RObert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> My feeling is that people do not use declare blocks NEARLY
> often enough.

I agree.

> Note that the issue of heaviness of syntax (and whether you
> need a marker between declarations and statements, which is
> the point Bob Duff has made) is quite orthogonal to the
> fundamental point that nested blocks are very valuable.

I agree that it's orthogonal.

However, I argue that the heavy syntax discourages their use.  Language
design principle:  Make it *easy* to use features that are safe, improve
readability, and all that good stuff -- don't weigh those features down
with extra rules and regulations, or extra syntax.

It's interesting to me that you like the heavy block-statement syntax,
but you gripe about the heavy procedure syntax (as compared to COBOL).
The actual syntactic overhead is the same, except for one extra blank
line in the procedure case.

- Bob

Re: Inheritance and Polymorphism in Ada !!

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> No, the procedure problem is *FAR* more fundamental. The
> requirement that you declare procedures before they are used is
> not just syntactic heaviness, it is just plain wrong when you
> are using procedures as refinements.

Shrug.  I guess I've gotten use to reading the code backwards when
that's appropriate.  ;-)
I do agree the COBOL way is kind of nice in this area.

Another problem with procedures (compared to blocks) is that a procedure
*has* to have a name, which is not always what you want.

- Bob

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article > In Python
>
> 	a,b = b,a
>
> Far more readable to me than anything C or Ada has to offer.
> Sorry, I couldn't resist either!

Well of course this notation (copied incidentally directly
from SETL) is more convenient, but that is besides the point
we are discussing here.




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Inheritance and Polymorphism in Ada !!

[Robert Dewar]

In article <wccr9ijqr6q.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> It's interesting to me that you like the heavy block-statement
syntax,
> but you gripe about the heavy procedure syntax (as compared to
COBOL).
> The actual syntactic overhead is the same, except for one
extra blank
> line in the procedure case.


No, the procedure problem is *FAR* more fundamental. The
requirement that you declare procedures before they are used is
not just syntactic heaviness, it is just plain wrong when you
are using procedures as refinements.


Sent via Deja.com http://www.deja.com/
Before you buy.