Problem trying to implement generics.

Problem trying to implement generics.

[Ayende Rahien]

I've just started to learn Ada, and I've some problem solving some problems.

Here is the spec I'm trying to compile:

with Ada.Finalization;
generic
 type data_type is private;
 type Sort_by is private;
package Binary_Trees is
 type binary_Tree is new Ada.Finalization.controlled with private;
 type node is private;
 type node_access is access all Node;
 type data_access is access all Data_type;
 procedure insert(insert_this : in data_type; Sort : in sort_by);
 --Insert into the binary tree, sort according to sort.
 function Delete(Delete_this: in Sort_by; Index : in natural := 1) return
boolean;
 -- Delete a node from the tree, return true if succeeded, return false if
 -- the node does not exist.
 function Get(Search_For: in sort_by; index : in natural := 1) return
data_access;
 -- Search for nodes with duplicate sort_by variable. It find the first
 -- node with the sort_by equal to the given one, and then continue to check
for Index
 -- number of duplicated. It return null if it there isn't a suitable node
in the
 -- correct index.
 private
  type Binary_Tree is new Ada.Finalization.controlled with record
   root: Node_access := null;
  end record;
  type node is record
   Data : Data_type;
   Sorted_by: Sort_by;
   Parent, Left, right : Node_access;
  end record;
     procedure Adjust(Object : in out Binary_Tree );
     procedure Finalize(Object : in out Binary_Tree );
end Binary_Trees;

I trying to put the defination of Node in the body, but it results in
compilation error, is there some way to put the defination in the body? Or
does it matter naught, because it's on the private part of the package?

Since it's a binary tree, I've to have > working on all types that sort_by
work on.
How do I force it?
At the moment, I've three compilation errors when I'm trying to use > on
sort_by data.
Here is the error:
bintree.adb: Error: line 43 col 25 LRM:8.4(1), Binary operator ">" between
Sort_by and Sort_by not directly visible, use clause or conversion might be
needed

This line also result in an error, and I don't know why:
procedure insert(insert_this : in data_type; Sort : in sort_by) is
Here is the error this line produce:
bintree.adb: Error: line 107 col 12 LRM:3.11.1(7), subprogram body is a
homograph of another subprogram which does not require a completion,
continuing

I also have this function:
 function Get(Search_For: in sort_by; index : in natural := 1) return
data_access is
  result : node_access := find(search_for,index);
 begin
  if result = null then
   return null;
  else
   return result.data'access;
  end if;
 end get;

find return a node_access, get translate it to data_access, I tried using
'access tag to make it return data_access, but it didn't qute work.
Here is the error:
bintree.adb: Error: line 150 col 18 LRM:3.10.2(23&31), The prefix to 'ACCESS
must be either an aliased view of an object or denote a subprogram with a
non-intrinsic calling convention, Continuing

Also I've a trouble using Root variable in a function that is undefied in
the spec (Find function).
I suppose I could put it in the private part, but can it be avoided?
Here is the error I got:
bintree.adb: Error: line 8 col 28 LRM:4.1(3), Direct name, root, is not
visible, Ignoring future references

Thanks in advance,
Ayende Rahien

Re: Problem trying to implement generics.

[tmoran]

>I've just started to learn Ada, and I've some problem solving some problems.
  If you are learning in a course, asking the instructor will be much
faster than asking here.  Assuming you are trying to learn just from
a book:
>I trying to put the defination of Node in the body, but it results in
>compilation error, is there some way to put the defination in the body? Or
>does it matter naught, because it's on the private part of the package?
  If Node is defined in the spec, the compiler needs to know things like
how big it is to generate assignments, etc.  Since the compiler cannot
look at the body (which may not even be written yet), the full definition
must be in the spec.  It's OK in the private part, as you have it now.

>Here is the error:
>bintree.adb: Error: line 43 col 25 LRM:8.4(1), Binary operator ">" between
  Without seeing line 43 (or any lines) of bintree.adb it's a little
hard to see what's going on, but, as the compiler suggests, a "use"
or "use type" might be what you need.

>procedure insert(insert_this : in data_type; Sort : in sort_by) is
>Here is the error this line produce:
>bintree.adb: Error: line 107 col 12 LRM:3.11.1(7), subprogram body is a
>homograph of another subprogram which does not require a completion,
  That sounds like you have two different "insert" subroutines which
look the same in calling parameters so if the compiler saw
 insert(a,b);
it wouldn't know which one to call.

>bintree.adb: Error: line 150 col 18 LRM:3.10.2(23&31), The prefix to 'ACCESS
>must be either an aliased view of an object or denote a subprogram with a
  Like the message says, the thing before 'access must be aliased.  Given
  type node is record
    Data : Data_type;
    ...
  type node_access is access all Node;
    ...
  result : node_access ...
  ...  result.data'access;
you see that "result.data" is defined as not aliased.  Try
    Data : aliased Data_type;

>Also I've a trouble using Root variable in a function that is undefied in
  Is the Root variable defined before the function that uses it?

When the compiler gives you an error message, it means it is doesn't
know what you want.  Occasionally, that's because the compiler is
stupid, but often, and in several of the cases above, there is no
way even the most clever compiler could know what you want.  So you
need to let the compiler know things like "actually, there's only
one 'procedure insert', Root is a variable I haven't told you about
yet, I did mean for Data to be aliased, though I didn't say it,
here's what Node looks like, so you can generate copying or
comparing code."

Re: Problem trying to implement generics.

[Ayende Rahien]

<tmoran@acm.org> wrote in message
news:zJ7B6.11026$ix4.8084250@news1.rdc1.sfba.home.com...
> >I've just started to learn Ada, and I've some problem solving some
problems.
>   If you are learning in a course, asking the instructor will be much
> faster than asking here.  Assuming you are trying to learn just from
> a book:

I'm learning from a book.


> >Here is the error:
> >bintree.adb: Error: line 43 col 25 LRM:8.4(1), Binary operator ">"
between
>   Without seeing line 43 (or any lines) of bintree.adb it's a little
> hard to see what's going on, but, as the compiler suggests, a "use"
> or "use type" might be what you need.

Here is the line:
if current.sorted_by > sort then

What does use type does? How do I use it?

> >procedure insert(insert_this : in data_type; Sort : in sort_by) is
> >Here is the error this line produce:
> >bintree.adb: Error: line 107 col 12 LRM:3.11.1(7), subprogram body is a
> >homograph of another subprogram which does not require a completion,
>   That sounds like you have two different "insert" subroutines which
> look the same in calling parameters so if the compiler saw
>  insert(a,b);
> it wouldn't know which one to call.

Yes, I found & fixed it, thanks.

> >bintree.adb: Error: line 150 col 18 LRM:3.10.2(23&31), The prefix to
'ACCESS
> >must be either an aliased view of an object or denote a subprogram with a
>   Like the message says, the thing before 'access must be aliased.  Given
>   type node is record
>     Data : Data_type;
>     ...
>   type node_access is access all Node;
>     ...
>   result : node_access ...
>   ...  result.data'access;
> you see that "result.data" is defined as not aliased.  Try
>     Data : aliased Data_type;

That solved the problem, but why? What does aliased mean?

> >Also I've a trouble using Root variable in a function that is undefied in
>   Is the Root variable defined before the function that uses it?

Yes, it's defined here:
type Binary_Tree is new Ada.Finalization.controlled with record
   root: Node_access := null;
  end record;

Which is on the ads file, and other functions doesn't seem to have trouble
finding it.
The only thing I can think of is that this doesn't work because the function
is not declared on the ads file.

Re: Problem trying to implement generics.

[tmoran]

> if current.sorted_by > sort then
As Andy <startrek.nospam@ozonline.com.au> pointed out in
message <3AD5B43F.6A5B@ozonline.com.au>, the problem is probably
that the compiler doesn't know how to compare two objects whose
type it doesn't know, and you therefore need to add a
  with function "<"
and give it a comparison function it can call.

> What does use type does? How do I use it?
  The book should explain that.  If it doesn't do a good job, try
a different book.  It's sort of a shorthand "use" that just applies
to operators imported from another package, so you don't have to say
x := other_package."+"(a,b);
but can say "x := a+b;"

> That solved the problem, but why? What does aliased mean?
  If you have a variable x, and also a pointer p that points to
x (p := x'access) then "x" and "p.all" are two different names,
or aliases, for the same thing.  Declaring "x : aliased some_type;"
alerts a reader of the program to the possibility the value of
x may change during a code sequence that appears to have to
mention of x (but has "p.all := 7;", for instance).  It also
tells the compiler that if it makes a temporary copy of x, in
a register, say, it must take account of the possibilty that
x is supposed to be changed by references to p.

>The only thing I can think of is that this doesn't work because the function
>is not declared on the ads file.
   Inside the body of the function, where the error occurs, it doesn't
matter where the spec of the function was first declared.  You say
other functions use this variable just fine.  What's different?

Re: Problem trying to implement generics.

[Ayende Rahien]

<tmoran@acm.org> wrote in message
news:PgmB6.11956$ix4.9222255@news1.rdc1.sfba.home.com...

> > That solved the problem, but why? What does aliased mean?
>   If you have a variable x, and also a pointer p that points to
> x (p := x'access) then "x" and "p.all" are two different names,
> or aliases, for the same thing.  Declaring "x : aliased some_type;"
> alerts a reader of the program to the possibility the value of
> x may change during a code sequence that appears to have to
> mention of x (but has "p.all := 7;", for instance).  It also
> tells the compiler that if it makes a temporary copy of x, in
> a register, say, it must take account of the possibilty that
> x is supposed to be changed by references to p.

Okay, that makes sense.

> >The only thing I can think of is that this doesn't work because the
function
> >is not declared on the ads file.
>    Inside the body of the function, where the error occurs, it doesn't
> matter where the spec of the function was first declared.  You say
> other functions use this variable just fine.  What's different?

I've no idea, I switched the places of the function with another procedure,
and it produce the same error in the procedure.
I also tried another compiler (I was using ObjectAda, tried GNAT), and got
the error on the same line.
The OS is Windows2000, ObjectAda 7.2 SE, GNAT 3.13.
I've no idea what I'm doing wrong here, as far as I know, it should compile.


The error from Object Ada is:
bintree.adb: Error: line 9 col 28 LRM:4.1(3), Direct name, root, is not
visible, Ignoring future references

The error from GNAT is:

bintree.adb:9:42: "root" is undefined (more references follow)

With nothing more to follow this.


Here is the spec:

with Ada.Finalization;
generic
 type data_type is private;
 type Sort_by is private;
 with function ">" (Left, Right: in Sort_By) return Boolean;
package binTree is
 type binary_Tree is new Ada.Finalization.controlled with private;
 type node is private;
 type node_access is access all Node;
 type data_access is access all Data_type;
 procedure insert(insert_this : in data_type; Sort : in sort_by);
 --Insert into the binary tree, sort according to sort.
 function Delete(Delete_this: in Sort_by; Index : in natural := 1) return
boolean;
 -- Delete a node from the tree, return true if succeeded, return false if
 -- the node does not exist.
 function Get(Search_For: in sort_by; index : in natural := 1) return
data_access;
 -- Search for nodes with duplicate sort_by variable. It find the first
 -- node with the sort_by equal to the given one, and then continue to check
for Index
 -- number of duplicated. It return null if it there isn't a suitable node
in the
 -- correct index.

 private
  type Binary_Tree is new Ada.Finalization.controlled with record
   root: Node_access := null;
  end record;
  type node is record
   Data : aliased Data_type;
   Sorted_by: Sort_by;
   Parent, Left, right : Node_access;
  end record;
     procedure Adjust(Object : in out Binary_Tree );
     procedure Finalize(Object : in out Binary_Tree );

end binTree;

Here is the body:

with Unchecked_Deallocation;

package body binTree is

 procedure Free is new Unchecked_Deallocation(node, Node_Access);

 procedure insert(insert_this : in data_type; Sort : in sort_by) is
  New_node : Node_Access := new node;
  current : Node_access := root; -- This is the line it compline about!!
 begin
  New_node.sorted_by := sort;
  New_node.data := insert_this;
  --if the tree is empty
  if root = null then
   root := new_node;
   return;
  end if;
  -- if tree is not empty
  loop
   if current.sorted_by > sort then
    if current.right /= null then
     current := current.right;
    else
     current.right := New_node;
     New_node.parent := current;
     return;
    end if;
   else
    if current.left /= null then
     current := current.left;
    else
     current.left := New_node;
     New_node.parent := current;
     return;
    end if;
   end if;
  end loop;
 end insert;

  function find(Find_This : in sort_by; index : in natural := 1) return
node_Access is
  current : node_access := root;
 begin
  while current /= null and current.sorted_by /= Find_This loop
   if current.sorted_by > Find_This then
    current := current.right;
   else
    current := current.left;
   end if;
  end loop;
  if index /= 0 and current /= null then
   for I in 1..index loop
    if current.left /= null and current.sorted_by = Find_This then
     current := current.left;
    else
     return null;
    end if;
   end loop;
  end if;
  return current;
 end Find;

 function Delete(Delete_this: in Sort_by; Index : in natural := 1) return
boolean is
  to_del: node_access := find(Delete_this,index);
  Lowest_Node : node_access;
 begin
  if to_del = null then
   return false;
  end if;
  --find the lower node to the left or to the right, so we can replace it.
  lowest_Node := to_del;
  while lowest_Node.left /= null or lowest_Node.right /= null loop
   if lowest_Node.left /= null then
    lowest_Node := lowest_Node.left;
   else
    lowest_Node := lowest_Node.right;
   end if;
  end loop;

  if Lowest_node.parent /= null then
   if lowest_Node.parent.left = lowest_Node then
    lowest_Node.parent.left := null;
   else
    lowest_Node.parent.right := null;
   end if;
  elsif root = Lowest_node then
   -- a single node tree which is about to lose its only leaf (the root one)
   root := null;
  end if;

  lowest_Node.parent := to_del.parent;
  lowest_Node.right := to_del.right;
  Lowest_node.left := Lowest_node.left;

  if lowest_Node.right /= null then
   lowest_Node.right.parent := lowest_Node;
  end if;

  if lowest_Node.left /= null then
   lowest_Node.left.parent := lowest_node;
  end if;

  Free(To_del);
  return true;
 end delete;


 function Get(Search_For: in sort_by; index : in natural := 1) return
data_access is
  result : node_access := find(search_for,index);
 begin
  if result = null then
   return null;
  else

   return   result.data'access;
  end if;
 end get;

 --erase this node and all that below this one
 procedure erase(node_to_del : in out Node_access) is
 begin
  if node_to_del.right /= null then
   erase(node_to_del.right);
  end if;

  if node_to_del.Left /= null then
   erase(node_to_del.Left);
  end if;

  free(node_to_del);
 end erase;

 --copy from_this node (and its children) to_this
 procedure copy(from_this: in node_access; to_this: out node_access;
to_this_parent : in node_access) is
 begin
  to_this := new node;
  to_this.data := from_this.data;
  to_this.sorted_by := from_this.sorted_by;
  to_this.parent := to_this_parent;
  if from_this.left /= null then
   copy(from_this.left,to_this.left,to_this);
  end if;
  if from_this.right /= null then
   copy(from_this.right,to_this.right,to_this);
  end if;
 end copy;

 procedure Finalize(Object : in out Binary_Tree ) is
  begin
  if root /= null then
   erase(root);
  end if;
 end finalize;

 procedure Adjust(Object : in out Binary_Tree ) is
  new_node : node_access;
 begin
  if root/=null then
   copy(root,root,null);
  end if;
 end adjust;

end binTree;

Re: Problem trying to implement generics.

[chris.danx]

Hi,

> The error from Object Ada is:
> bintree.adb: Error: line 9 col 28 LRM:4.1(3), Direct name, root, is not
> visible, Ignoring future references
>
> The error from GNAT is:
>
> bintree.adb:9:42: "root" is undefined (more references follow)
>
> With nothing more to follow this.

Ok, this means it's not found a definition for it.  It doesn't know what or
where it is.  You probably know that.

[SNIP]

>  private
>   type Binary_Tree is new Ada.Finalization.controlled with record
>    root: Node_access := null;
>   end record;

the error comes because

> package body binTree is
[snip]
>  procedure insert(insert_this : in data_type; Sort : in sort_by) is
>   New_node : Node_Access := new node;
>   current : Node_access := root; -- This is the line it compline about!!

you've forgot to that Root is in Binary_Tree.

I have a question.  From your code it doesn't look like an ADT.  Is this
what you intended?  I can't remember the term for what this looks like, but
I think it's to do with storing the Tree as a global variable in the package
not as an ADT.

If you want an ADT you need to pass in a Binary_Tree type as necessary.  I
didn't see it any where in your code so i'm assuming it's based on a global
variable.

There's nothing wrong doing it this way!


Regards,
Chris Campbell

Re: Problem trying to implement generics.

[Ayende Rahien]

"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:PDAB6.10174$FD1.1166748@news6-win.server.ntlworld.com...
> Hi,
>
> > The error from Object Ada is:
> > bintree.adb: Error: line 9 col 28 LRM:4.1(3), Direct name, root, is not
> > visible, Ignoring future references
> >
> > The error from GNAT is:
> >
> > bintree.adb:9:42: "root" is undefined (more references follow)
> >
> > With nothing more to follow this.
>
> Ok, this means it's not found a definition for it.  It doesn't know what
or
> where it is.  You probably know that.
>
> [SNIP]
>
> >  private
> >   type Binary_Tree is new Ada.Finalization.controlled with record
> >    root: Node_access := null;
> >   end record;
>
> the error comes because
>
> > package body binTree is
> [snip]
> >  procedure insert(insert_this : in data_type; Sort : in sort_by) is
> >   New_node : Node_Access := new node;
> >   current : Node_access := root; -- This is the line it compline about!!
>
> you've forgot to that Root is in Binary_Tree.

Okay, so how do I fix it? And what is wrong, anyway?

> I have a question.  From your code it doesn't look like an ADT.  Is this
> what you intended?  I can't remember the term for what this looks like,
but
> I think it's to do with storing the Tree as a global variable in the
package
> not as an ADT.

Okay, major cocept problem here.
I'm coming here with C/C++ background, and I understand that Ada has a
different OO paradigm.
I assumed that for each Binary_Tree spesific type that I create, there would
be its own Root.
I mean:
package Int_BinTree is new Binary_Tree(data_type=>
Integer,Sort_by=>Integer);

Bin_Tree_First, Bin_Tree_Second : Int_BinTree;

Does Bin_Tree_First.Root = Bin_Tree_Second.Root ?


> If you want an ADT you need to pass in a Binary_Tree type as necessary.  I
> didn't see it any where in your code so i'm assuming it's based on a
global
> variable.

I think that you are talking about ADO vs ADT , right?
generic abstract data type & generic abstract data object

> There's nothing wrong doing it this way!

Then why doesn't it compile?

Re: Problem trying to implement generics.

[chris.danx]

> >
> > >  private
> > >   type Binary_Tree is new Ada.Finalization.controlled with record
> > >    root: Node_access := null;
> > >   end record;
> >
> > the error comes because
> >
> > > package body binTree is
> > [snip]
> > >  procedure insert(insert_this : in data_type; Sort : in sort_by) is
> > >   New_node : Node_Access := new node;
> > >   current : Node_access := root; -- This is the line it compline
about!!
> >
> > you've forgot to that Root is in Binary_Tree.
>
> Okay, so how do I fix it? And what is wrong, anyway?

What you do is pass in a Binary_Tree type with appropriate mode.  In C++ you
have objects that store the methods with the data in the class.  This means
you don't need to refer to the object name and you can just use "root".  In
Ada methods are simply procedures and functions that work with objects
passed in.

In C++ you'd have

    BinTree.insert(insert_this, sort);

but in Ada

    insert(BinTree, insert_this, sort);

You use the methods with the object type.  So you'd have to pass in an item
of type Binary_Tree with appropriate mode and use the "root" field in this.

e.g.
    procedure insert (BT            :     in out Binary_Tree;
                                insert_this : ...
                                sort          : ...) is
        New_node : Node_Access := new node;
        current : Node_access := BT.root; -- This is what you need to do!
    begin
        .........................
        .........................
    end insert;

If your interested i have a generic doubly linked list ADT written in Ada.
It's part of the Heather modules i'm writing.  I know it isn't based on
tagged types(Ada objects), but it does show how to build an ADT.  Your
implementation of Binary_Tree is "Limited controlled" which means it's a
tagged type, but i haven't added this property to it yet.  I may soon, or at
least make it controlled.  It really doesn't matter that much since it's
just an example.

I will put it up on my site if you let me know you want it.


>
> > I have a question.  From your code it doesn't look like an ADT.  Is this
> > what you intended?  I can't remember the term for what this looks like,
> but
> > I think it's to do with storing the Tree as a global variable in the
> package
> > not as an ADT.
>
> Okay, major cocept problem here.
> I'm coming here with C/C++ background, and I understand that Ada has a
> different OO paradigm.
> I assumed that for each Binary_Tree spesific type that I create, there
would
> be its own Root.
> I mean:
> package Int_BinTree is new Binary_Tree(data_type=>
> Integer,Sort_by=>Integer);
>
> Bin_Tree_First, Bin_Tree_Second : Int_BinTree;
>
> Does Bin_Tree_First.Root = Bin_Tree_Second.Root ?
>
>
> > If you want an ADT you need to pass in a Binary_Tree type as necessary.
I
> > didn't see it any where in your code so i'm assuming it's based on a
> global
> > variable.
>
> I think that you are talking about ADO vs ADT , right?
> generic abstract data type & generic abstract data object

Yes, that's it.  ADO -- i must remember that!


> > There's nothing wrong doing it this way!
>
> Then why doesn't it compile?

It doesn't compile because Ada's OO is based on extensible records.  You
have to pass the record in even though it's an Object.  In C++ the object
methods are held inside the class which means they have access to the
variables inside.  This is not the same as Ada.

Maybe, this is a better explanation, it's just like C records.  Just pass in
the record and use it as you wish.  Remember to get the correct mode, and
use the record like you would in C.

There's more to Ada's OO but you don't need it for your Binary_Tree and I'm
still learning about it myself.


Regards,
Chris Campbell

Re: Problem trying to implement generics.

[Ayende Rahien]

"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:0JBB6.10484$FD1.1197250@news6-win.server.ntlworld.com...
>
> > >
> > > >  private
> > > >   type Binary_Tree is new Ada.Finalization.controlled with record
> > > >    root: Node_access := null;
> > > >   end record;
> > >
> > > the error comes because
> > >
> > > > package body binTree is
> > > [snip]
> > > >  procedure insert(insert_this : in data_type; Sort : in sort_by) is
> > > >   New_node : Node_Access := new node;
> > > >   current : Node_access := root; -- This is the line it compline
> about!!
> > >
> > > you've forgot to that Root is in Binary_Tree.
> >
> > Okay, so how do I fix it? And what is wrong, anyway?
>
> What you do is pass in a Binary_Tree type with appropriate mode.  In C++
you
> have objects that store the methods with the data in the class.  This
means
> you don't need to refer to the object name and you can just use "root".
In
> Ada methods are simply procedures and functions that work with objects
> passed in.
>
> In C++ you'd have
>
>     BinTree.insert(insert_this, sort);
>
> but in Ada
>
>     insert(BinTree, insert_this, sort);
>
> You use the methods with the object type.  So you'd have to pass in an
item
> of type Binary_Tree with appropriate mode and use the "root" field in
this.
>
> e.g.
>     procedure insert (BT            :     in out Binary_Tree;
>                                 insert_this : ...
>                                 sort          : ...) is
>         New_node : Node_Access := new node;
>         current : Node_access := BT.root; -- This is what you need to do!
>     begin
>         .........................
>         .........................
>     end insert;
>
> If your interested i have a generic doubly linked list ADT written in Ada.
> It's part of the Heather modules i'm writing.  I know it isn't based on
> tagged types(Ada objects), but it does show how to build an ADT.  Your
> implementation of Binary_Tree is "Limited controlled" which means it's a
> tagged type, but i haven't added this property to it yet.  I may soon, or
at
> least make it controlled.  It really doesn't matter that much since it's
> just an example.
>
> I will put it up on my site if you let me know you want it.

Maybe later, right now I want to implement those myself, it's a good
practice, and make for excellent tools afterward.


> > > I have a question.  From your code it doesn't look like an ADT.  Is
this
> > > what you intended?  I can't remember the term for what this looks
like,
> > but
> > > I think it's to do with storing the Tree as a global variable in the
> > package
> > > not as an ADT.
> >
> > Okay, major cocept problem here.
> > I'm coming here with C/C++ background, and I understand that Ada has a
> > different OO paradigm.
> > I assumed that for each Binary_Tree spesific type that I create, there
> would
> > be its own Root.
> > I mean:
> > package Int_BinTree is new Binary_Tree(data_type=>
> > Integer,Sort_by=>Integer);
> >
> > Bin_Tree_First, Bin_Tree_Second : Int_BinTree;
> >
> > Does Bin_Tree_First.Root = Bin_Tree_Second.Root ?
> >
> >
> > > If you want an ADT you need to pass in a Binary_Tree type as
necessary.
> I
> > > didn't see it any where in your code so i'm assuming it's based on a
> > global
> > > variable.
> >
> > I think that you are talking about ADO vs ADT , right?
> > generic abstract data type & generic abstract data object
>
> Yes, that's it.  ADO -- i must remember that!
>
>
> > > There's nothing wrong doing it this way!
> >
> > Then why doesn't it compile?
>
> It doesn't compile because Ada's OO is based on extensible records.  You
> have to pass the record in even though it's an Object.  In C++ the object
> methods are held inside the class which means they have access to the
> variables inside.  This is not the same as Ada.
>
> Maybe, this is a better explanation, it's just like C records.  Just pass
in
> the record and use it as you wish.  Remember to get the correct mode, and
> use the record like you would in C.
>
> There's more to Ada's OO but you don't need it for your Binary_Tree and
I'm
> still learning about it myself.

Thanks, that helped, it now compiles.
BTW, is there any reason why I can't use out parameter with a function?

Re: Problem trying to implement generics.

[Robert A Duff]

"Ayende Rahien" <Dont@spam.me> writes:

> BTW, is there any reason why I can't use out parameter with a function?

Because it's not allowed.  ;-)

Hmm, are we going have this argument again?  Oh well, it's kind of fun,
in a time-wasting sort of way.  Here goes:

If I ran the circus, functions would be allowed to have 'out' and 'in
out' parameters.

- Bob

P.S. One workaround is to use access parameters.

Another workaround is to declare a limited type, with a component that
always points to itself:

    type T is tagged limited
        record
            Self_Reference: T_Ptr := T'Unchecked_Access;
            ...
        end record;

If you pass this thing as an 'in' parameter to a function, the function
can modify it by following the Self_Reference pointer.  This works
because no constant objects of type T can exist.  It seems a lot like
"cheating", doesn't it?

Re: Problem trying to implement generics.

[Brian Rogoff]

On Fri, 13 Apr 2001, Robert A Duff wrote:
> "Ayende Rahien" <Dont@spam.me> writes:
> 
> > BTW, is there any reason why I can't use out parameter with a function?
> 
> Because it's not allowed.  ;-)
> 
> Hmm, are we going have this argument again?  Oh well, it's kind of fun,
> in a time-wasting sort of way.  Here goes:
> 
> If I ran the circus, functions would be allowed to have 'out' and 'in
> out' parameters.

Or, would you just allow procedures to return values? ;-)

Oh well, you're right, this is a time waster (but just too fun to ignore:). 

> Another workaround is to declare a limited type, with a component that
> always points to itself:
> 
>     type T is tagged limited
>         record
>             Self_Reference: T_Ptr := T'Unchecked_Access;
>             ...
>         end record;
> 
> If you pass this thing as an 'in' parameter to a function, the function
> can modify it by following the Self_Reference pointer.  This works
> because no constant objects of type T can exist.  It seems a lot like
> "cheating", doesn't it?

Did anyone see this during the Ada 95 design? I thought J.P. Rosen (who
showed most of us this evil trick :) said something about having noticed
it early but never actually implementing it until later. I'm sure I'm
botching the story: J.P, what's the history here?

-- Brian

Re: Problem trying to implement generics.

[Ayende Rahien]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0104131658480.17102-100000@shell5.ba.best.com...
> On Fri, 13 Apr 2001, Robert A Duff wrote:
> > "Ayende Rahien" <Dont@spam.me> writes:
> >
> > > BTW, is there any reason why I can't use out parameter with a
function?
> >
> > Because it's not allowed.  ;-)
> >
> > Hmm, are we going have this argument again?  Oh well, it's kind of fun,
> > in a time-wasting sort of way.  Here goes:
> >
> > If I ran the circus, functions would be allowed to have 'out' and 'in
> > out' parameters.
>
> Or, would you just allow procedures to return values? ;-)

No, but I would like to have a function that I can place in an if (etc) that
change the variables I gives it. It's not a big deal, I was just wondering
what was the reason for this decistion.

Re: Problem trying to implement generics.

[Brian Rogoff]

On Sat, 14 Apr 2001, Ayende Rahien wrote:
> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > Or, would you just allow procedures to return values? ;-)
> 
> No, but I would like to have a function that I can place in an if (etc) that
> change the variables I gives it. 

You can achieve this with access parameters, or the trick that Robert Duff
described (which obviously only works for limited types). 

> It's not a big deal, I was just wondering what was the reason for this decistion.

A desire to have Ada functions correspond more closely to mathematical
functions, which don't modify their arguments? I think in general it is
good style *not* to have functions modifying their arguments, but as usual 
there are relatively rare exceptions. I think it would have been better to 
allow out and in-out params, and make sure that programmers who abuse them 
are beaten severely. 

You're right, it shouldn't be too big of a deal for you. And I doubt it
will ever change in any future version of Ada, since enough people seem 
to really like this restriction.

-- Brian

Re: Problem trying to implement generics.

[Dmitry A. Kazakov]

Brian Rogoff wrote:

> On Sat, 14 Apr 2001, Ayende Rahien wrote:
> 
>> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
>> 
>>> Or, would you just allow procedures to return values? ;-)
>> 
>> No, but I would like to have a function that I can place in an if (etc) that
>> change the variables I gives it. 
> 
> You can achieve this with access parameters, or the trick that Robert Duff
> described (which obviously only works for limited types). 
> 
>> It's not a big deal, I was just wondering what was the reason for this decistion.
> 
> A desire to have Ada functions correspond more closely to mathematical
> functions, which don't modify their arguments? I think in general it is
> good style *not* to have functions modifying their arguments, but as usual 
> there are relatively rare exceptions. I think it would have been better to 
> allow out and in-out params, and make sure that programmers who abuse them 
> are beaten severely. 
> 
> You're right, it shouldn't be too big of a deal for you. And I doubt it
> will ever change in any future version of Ada, since enough people seem 
> to really like this restriction.

Well, but what I still cannot understand, what is the objection against 
*procedures* returning a value:

procedure Foo (...) return ...;

A related question is a syntax sugar to ignore unused result of an expression. For instance, instead of clumsy

declare
    Dummy : Integer;
begin
    Dummy := Some_API_Call (...);
end;

something like:

null Some_API_Call (...);

Regards,
Dmitry Kazakov

Re: Problem trying to implement generics.

[Ayende Rahien]

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3AD858A3.3070803@elros.cbb-automation.de...
>
>
> Brian Rogoff wrote:
>
> > On Sat, 14 Apr 2001, Ayende Rahien wrote:
> >
> >> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> >>
> >>> Or, would you just allow procedures to return values? ;-)
> >>
> >> No, but I would like to have a function that I can place in an if (etc)
that
> >> change the variables I gives it.
> >
> > You can achieve this with access parameters, or the trick that Robert
Duff
> > described (which obviously only works for limited types).
> >
> >> It's not a big deal, I was just wondering what was the reason for this
decistion.
> >
> > A desire to have Ada functions correspond more closely to mathematical
> > functions, which don't modify their arguments? I think in general it is
> > good style *not* to have functions modifying their arguments, but as
usual
> > there are relatively rare exceptions. I think it would have been better
to
> > allow out and in-out params, and make sure that programmers who abuse
them
> > are beaten severely.
> >
> > You're right, it shouldn't be too big of a deal for you. And I doubt it
> > will ever change in any future version of Ada, since enough people seem
> > to really like this restriction.
>
> Well, but what I still cannot understand, what is the objection against
> *procedures* returning a value:

Because that is the difference between functions & procedures?
If you wanted it that way, you could do this:
function Foo(...) return nothing;

But I agree that it would be nice to be able to ignore function's return
value.

> procedure Foo (...) return ...;
>
> A related question is a syntax sugar to ignore unused result of an
expression. For instance, instead of clumsy
>
> declare
>     Dummy : Integer;
> begin
>     Dummy := Some_API_Call (...);
> end;
>
> something like:
>
> null Some_API_Call (...);
>
> Regards,
> Dmitry Kazakov
>

Re: Problem trying to implement generics.

[Michael Erdmann]

Ayende Rahien schrieb:

> "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
> news:3AD858A3.3070803@elros.cbb-automation.de...
> >
>
> > >
> > > You're right, it shouldn't be too big of a deal for you. And I doubt it
> > > will ever change in any future version of Ada, since enough people seem
> > > to really like this restriction.
> >
> > Well, but what I still cannot understand, what is the objection against
> > *procedures* returning a value:
>
> Because that is the difference between functions & procedures?
> If you wanted it that way, you could do this:
> function Foo(...) return nothing;
>
> But I agree that it would be nice to be able to ignore function's return
> value.
>

I  dont agree on this.  Ada is everything about security, the compiler
shall be able to warn you, that you have forgotten to evaluate the
return value of a function!

Rgeards
  M.Erdmann

Re: Problem trying to implement generics.

[James Rogers]

Ayende Rahien wrote:
> 
> "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
> news:3AD858A3.3070803@elros.cbb-automation.de...
> > Well, but what I still cannot understand, what is the objection against
> > *procedures* returning a value:
> 
> Because that is the difference between functions & procedures?
> If you wanted it that way, you could do this:
> function Foo(...) return nothing;
> 
> But I agree that it would be nice to be able to ignore function's return
> value.

A procedure may modify parameters, but may not return a value.

The practice in C, C++, and Java of ignoring return values from 
functions or methods may seem very convenient. In fact it is a
fundamental violation of the contract defined for a function. This
is the single greatest reason exceptions were added to C++, and
included from the start in Java. A common C programming paradigm
is to have a function return an indication of success or failure.
That same function may also modify some or all parameter values.
It is also very common in C to ignore the return value of a
function. What is the obvious problem? If the return value
indicates success or failure, and that value is ignored, then the
programmer is ensuring erroneous execution. Whenever the function
fails, the programmer using that function continues to use the
modified parameter values as though the function succeeded. This
usually leads to very difficult debugging sessions because the error
may not become obvious in the program until some later code block.
It also relies upon the sometimes lucky choice of test cases to 
generate the error condition. If your test cases do not generate
the error, then you will release erroneous code to your 
customer, which they will find for you, usually at significant
expense for your company.

In Ada you have a very strong contract concerning procedures and
functions. Functions always return a value. That value has significant
meaning. It cannot be ignored. Procedures are the form of subprogram
to use when no significant value is to be returned.

Jim Rogers
Colorado Springs, Colorado USA

Re: Problem trying to implement generics.

[Ayende Rahien]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3AD915C2.321EB048@worldnet.att.net...
> Ayende Rahien wrote:
> >
> > "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
> > news:3AD858A3.3070803@elros.cbb-automation.de...
> > > Well, but what I still cannot understand, what is the objection
against
> > > *procedures* returning a value:
> >
> > Because that is the difference between functions & procedures?
> > If you wanted it that way, you could do this:
> > function Foo(...) return nothing;
> >
> > But I agree that it would be nice to be able to ignore function's return
> > value.
>
> A procedure may modify parameters, but may not return a value.
>
> The practice in C, C++, and Java of ignoring return values from
> functions or methods may seem very convenient. In fact it is a
> fundamental violation of the contract defined for a function. This
> is the single greatest reason exceptions were added to C++, and
> included from the start in Java.

I thought that they added exceptions because of this type of functions:
int & Foo();
Where there is no return value that you can use for errors.
For the rest, I agree.


> A common C programming paradigm
> is to have a function return an indication of success or failure.
> That same function may also modify some or all parameter values.
> It is also very common in C to ignore the return value of a
> function. What is the obvious problem? If the return value
> indicates success or failure, and that value is ignored, then the
> programmer is ensuring erroneous execution. Whenever the function
> fails, the programmer using that function continues to use the
> modified parameter values as though the function succeeded. This
> usually leads to very difficult debugging sessions because the error
> may not become obvious in the program until some later code block.
> It also relies upon the sometimes lucky choice of test cases to
> generate the error condition. If your test cases do not generate
> the error, then you will release erroneous code to your
> customer, which they will find for you, usually at significant
> expense for your company.
>
> In Ada you have a very strong contract concerning procedures and
> functions. Functions always return a value. That value has significant
> meaning. It cannot be ignored. Procedures are the form of subprogram
> to use when no significant value is to be returned.
>
> Jim Rogers
> Colorado Springs, Colorado USA

Re: Problem trying to implement generics.

[Dmitry A. Kazakov]

James Rogers wrote:

> Ayende Rahien wrote:
> 
>> "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
>> news:3AD858A3.3070803@elros.cbb-automation.de...
>> 
>>> Well, but what I still cannot understand, what is the objection against
>>> *procedures* returning a value:
>> 
>> Because that is the difference between functions & procedures?
>> If you wanted it that way, you could do this:
>> function Foo(...) return nothing;
>> 
>> But I agree that it would be nice to be able to ignore function's return
>> value.
> 
> A procedure may modify parameters, but may not return a value.

Why? There are lot of cases where a procedure with a result would be 
natural: random generator, memory allocator, table search etc.

> The practice in C, C++, and Java of ignoring return values from 
> functions or methods may seem very convenient. In fact it is a
> fundamental violation of the contract defined for a function. This
> is the single greatest reason exceptions were added to C++, and
> included from the start in Java. A common C programming paradigm
> is to have a function return an indication of success or failure.
> That same function may also modify some or all parameter values.
> It is also very common in C to ignore the return value of a
> function. What is the obvious problem? If the return value
> indicates success or failure and that value is ignored, then the

The practice is exactly the point. Take a look at Windows API. You will 
discover functions returning values which nobody needs and modifying 
parameters as well as global system state.

Then I absolutely agree with you that ignoring the return value 
indicates a potential problem, therefore I would like to have a syntax 
construct for this, that will alert a code reader. Just like 
"unchecked_access". Moreover, I would like to have some syntax sugar for 
dummy [in]out parameters, but I have no idea how it cold look like.

Regards,
Dmitry Kazakov

Re: Problem trying to implement generics.

[tmoran]

>Then I absolutely agree with you that ignoring the return value
>indicates a potential problem, therefore I would like to have a syntax
>construct for this, that will alert a code reader. Just like
  procedure Ignoring(Return_Value : in Interfaces.C.Int) is
  begin null;end Ignoring;

  ...; Ignoring(Some_Function(X, Y, Z'access)); ...

Re: Problem trying to implement generics.

[Dmitry A. Kazakov]

Ayende Rahien wrote:

> "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
> news:3AD858A3.3070803@elros.cbb-automation.de...
> 
>> Well, but what I still cannot understand, what is the objection against
>> *procedures* returning a value:
>  
> Because that is the difference between functions & procedures?

The difference between them is that a function may (supposedly) have no 
side effects and hence no [in]out parameters. Function is (I am trying 
to follow rigorous point of view) an attempt to model mathematical mappings.

Procedure is a more general thing than function, so it is not clear why 
it may not have a dedicated out parameter called result:

procedure <name> [<parameter-list>] [return <result-type>];

Regards,
Dmitry Kazakov

Re: Problem trying to implement generics.

[Ayende Rahien]

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3AD9A697.8080402@elros.cbb-automation.de...
>
>
> Ayende Rahien wrote:
>
> > "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
> > news:3AD858A3.3070803@elros.cbb-automation.de...
> >
> >> Well, but what I still cannot understand, what is the objection against
> >> *procedures* returning a value:
> >
> > Because that is the difference between functions & procedures?
>
> The difference between them is that a function may (supposedly) have no
> side effects and hence no [in]out parameters. Function is (I am trying
> to follow rigorous point of view) an attempt to model mathematical
mappings.

Do you mean that it's similar to const fucntions in C++?

> Procedure is a more general thing than function, so it is not clear why
> it may not have a dedicated out parameter called result:
>
> procedure <name> [<parameter-list>] [return <result-type>];

Well, I certainly agree with your point here.

Re: Problem trying to implement generics.

[Dmitry A. Kazakov]

On Sun, 15 Apr 2001 22:44:23 +0200, "Ayende Rahien" <Dont@spam.me>
wrote:

>"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
>news:3AD9A697.8080402@elros.cbb-automation.de...
>>
>>
>> Ayende Rahien wrote:
>>
>> > "Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
>> > news:3AD858A3.3070803@elros.cbb-automation.de...
>> >
>> >> Well, but what I still cannot understand, what is the objection against
>> >> *procedures* returning a value:
>> >
>> > Because that is the difference between functions & procedures?
>>
>> The difference between them is that a function may (supposedly) have no
>> side effects and hence no [in]out parameters. Function is (I am trying
>> to follow rigorous point of view) an attempt to model mathematical
>mappings.
>
>Do you mean that it's similar to const fucntions in C++?

I think Ada's functions are similar to ones in C++, which have all
parameters const. Though both only mimic mathematical mappings
(functions), for a programmer always has an ability to achive side
effects.

Moreover no routine can have no side effects. Something allways
happens upon its call. For instance the process working page set may
be extended in the result of a function call, etc.

So it is mostly about which side effects are counted for relevant and
which not. From my point of view there is nothing wrong which a
*function* that reads a character from the file. Yes it changes the
state of the file, but this effect is not relevant to me, as well as
one that the operator should move the mouse and press a button to
deliver me that character. If I would like for some reason to ensure
that the file state is not changed, then I would pass it as an
in-parameter and would be awarded with a compilation error, because an
inout-parameter is required. It is stone-safe. So in my opinion the
distiction between functions and procedures is rather unnatural. But
it would OK if procedures could return values.

Regards,
Dmitry Kazakov

Re: Problem trying to implement generics.

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> Or, would you just allow procedures to return values? ;-)

Yeah.  ;-)

> Did anyone see this during the Ada 95 design? I thought J.P. Rosen (who
> showed most of us this evil trick :) said something about having noticed
> it early but never actually implementing it until later. I'm sure I'm
> botching the story: J.P, what's the history here?

I think I discovered it independently of J.P. Rosen, sometime *after*
the Ada 95 standard.  I wrote in AARM-7.5(1.a):

        1.a   Discussion:  The concept of the value of a limited type is
        difficult to define, since the abstract value of a limited type often
        extends beyond its physical representation.  In some sense, values of
        a limited type cannot be divorced from their object.  The value IS
        the object.

Or maybe Tucker wrote that.  I don't really remember, since we traded
off writing assignments so often, and we were in tune with each other's
thinking.  Anyway, I don't think I realized the full ramifications of
"the value IS the object" until after the 9X design was over.

- Bob

Re: Problem trying to implement generics.

[Jean-Pierre Rosen]

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


"Brian Rogoff" <bpr@shell5.ba.best.com> a �crit dans le message news:
Pine.BSF.4.21.0104131658480.17102-100000@shell5.ba.best.com...
> > Another workaround is to declare a limited type, with a component that
> > always points to itself:
> >
> >     type T is tagged limited
> >         record
> >             Self_Reference: T_Ptr := T'Unchecked_Access;
> >             ...
> >         end record;
> >
> > If you pass this thing as an 'in' parameter to a function, the function
> > can modify it by following the Self_Reference pointer.  This works
> > because no constant objects of type T can exist.  It seems a lot like
> > "cheating", doesn't it?
>
Actually, my version is slightly more sophisticated than that . It uses an
access discriminant, avoiding the need for Unchecked_Access. See
http://www.adapower.com/lang/modifyin.html
If you consider that functions should not modify their parameters, then any
trick that allows you to modify parameters is "cheating". Now, there are two
nice things with this trick:
1) various rules of the language make sure that it can be used only where it
is safe (no dangling pointers, no pointers to the wrong thing, etc.).
2) It requires a special structure in the type itself. Therefore, it's not
the function that decides to modify the parameter, it is the parameter that
tells the function that it accepts to be modified. It's like the designer
("owner") of the type putting some special notice: "by exception to the
rule, I allow functions to modify this data". I think it removes most of the
"evil" of functions modifying parameters.

> Did anyone see this during the Ada 95 design? I thought J.P. Rosen (who
> showed most of us this evil trick :) said something about having noticed
> it early but never actually implementing it until later. I'm sure I'm
> botching the story: J.P, what's the history here?
>
I realized this possibility initially during a review meeting of tests for
access discriminants (I was a member of the ACVC/9X reviewers team). Did I
mention it at that time ? I don't remember, but if I did, it apparently went
unnoticed. Then we had that discussion about functions-modifying-parameters
on c.l.a, and I took the opportunity to address a wider audience...

BTW: one of the fascinating things with Ada is that you discover every day
paradigms, design patterns, whatever, that show that the language is even
*more* powerful than you thought. You think "wow, this is allowed by the
language. Could it possibly work?". You try it, and it's OK.

Well, I can't resist. One of my favorite ones (back in Ada83 times) is when
you have a common treatment for all exceptions, then you want to dispatch
according to the exception actually raised. For example, you have a local
file open, and you want to close it in case of an exception, then do
something.

procedure proc is
   F : File_Type;
begin
   ...
   Open (F, ...);
   ...
exception
   when others =>
      if Is_Open (F) then
         Close (F);
      end if;
      begin
         raise;   -- Reraise current exception
      exception
         when Constraint_Error =>
              ...
         when Data_Error =>
             ...
          ...
      end;
end Proc;

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Problem trying to implement generics.

[Tucker Taft]

Robert A Duff wrote:
> 
> "Ayende Rahien" <Dont@spam.me> writes:
> 
> > BTW, is there any reason why I can't use out parameter with a function?
> 
> Because it's not allowed.  ;-)
> 
> Hmm, are we going have this argument again?  Oh well, it's kind of fun,
> in a time-wasting sort of way.  Here goes:
> 
> If I ran the circus, functions would be allowed to have 'out' and 'in
> out' parameters.

It would be interesting to see where such functions would
typically be used.  My experience is that the most common
uses for such functions are:
   1) Returning a status value (probably better handled with
        exceptions in Ada)
   2) Using in a "while" loop, such as:
         while Get_Next(Iterator, Val) loop
             ...
         end loop;

My own objection to having functions with OUT parameters is
that it increases the possibility for confusion for the
reader.  When you see a procedure call, there is little doubt
that it is being called for its side-effects.  When you see
a function call (except in certain stylized locations such
as the "while" condition above), you presume it is being
called for its value, or at least it won't directly change
the value of some elementary parameter passed to it.

I wonder if we might create a new loop syntax to accommodate
the "while" case above, without opening up the function-with-
out-parameters box.

Alternatively, just get used to one of the idioms:

    loop
        Get_Next(Iterator, Val, Done);
      exit when Done;
        ...
    end loop;

or
    while More(Iterator) loop
        Get_Next(Iterator, Val);
        ...
    end loop;

Interestingly enough, the standard Iterator in Java
uses:
     while (Iter.hasNext()) {
         X = Iter.next();
         ...
     }

even though Java has functions with side effects (although
in fact, only with side-effects on by-reference operands,
since it has no parameter modes at all!).

-Tuck

> 
> - Bob
> 
> P.S. One workaround is to use access parameters.

Note, that "C" uses essentially the same "workaround" since
C has no "out" parameters.

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: Problem trying to implement generics.

[Ayende Rahien]

"Tucker Taft" <stt@averstar.com> wrote in message
news:3ADC4320.7ACA3DEC@averstar.com...

> Interestingly enough, the standard Iterator in Java
> uses:
>      while (Iter.hasNext()) {
>          X = Iter.next();
>          ...
>      }
>
> even though Java has functions with side effects (although
> in fact, only with side-effects on by-reference operands,
> since it has no parameter modes at all!).

Why use it like this?
for (;Iter.hasNext(); X = Iter.next() ){
    //do stuff
}

Is much more readable, IMO.

Re: Problem trying to implement generics.

[Larry Hazel]

Ayende Rahien wrote:
> 
> "Tucker Taft" <stt@averstar.com> wrote in message
> news:3ADC4320.7ACA3DEC@averstar.com...
> 
> > Interestingly enough, the standard Iterator in Java
> > uses:
> >      while (Iter.hasNext()) {
> >          X = Iter.next();
> >          ...
> >      }
> >
> > even though Java has functions with side effects (although
> > in fact, only with side-effects on by-reference operands,
> > since it has no parameter modes at all!).
> 
> Why use it like this?
> for (;Iter.hasNext(); X = Iter.next() ){
>     //do stuff
> }
> 
> Is much more readable, IMO.

I disagree.  The C style for loop is totally unreadable garbage IMO.  In what
little C programming I have done, I refused to use for loops.  Of course, I also
refused to use ++, --, +=, and all the other wierd C operators.  Matter of
taste, I guess.

Larry

Re: Problem trying to implement generics.

[Brian Rogoff]

On Tue, 17 Apr 2001, Larry Hazel wrote:
> Ayende Rahien wrote:
> > 
> > "Tucker Taft" <stt@averstar.com> wrote in message
> > news:3ADC4320.7ACA3DEC@averstar.com...
> > 
> > > Interestingly enough, the standard Iterator in Java
> > > uses:
> > >      while (Iter.hasNext()) {
> > >          X = Iter.next();
> > >          ...
> > >      }
> > >
> > > even though Java has functions with side effects (although
> > > in fact, only with side-effects on by-reference operands,
> > > since it has no parameter modes at all!).
> > 
> > Why use it like this?
> > for (;Iter.hasNext(); X = Iter.next() ){
> >     //do stuff
> > }
> > 
> > Is much more readable, IMO.
> 
> I disagree.  The C style for loop is totally unreadable garbage IMO. 

Well, to a C programmer the for loop is perfectly readable. As someone
familiar with C, Java, Ada, and a few other languages, I have to say that 
I found Tucker's original expression far preferable to Ayende's,
though I'd prefer "hasMore" to "hasNext" :-). Ayende, why do you find the
for loop preferable in this case? 

As long as we're considering iterators, it should be mentioned that
iterators are one of the great examples for adding downward funargs into
the language. 

> In what little C programming I have done, I refused to use for loops.  

Did you use macros to set { and } to BEGIN and END too? 

> Of course, I also refused to use ++, --, +=, and all the other
> wierd C operators.  Matter of taste, I guess.

Indeed, some people have a problem adapting to the features of other
languages. 

-- Brian

Re: Problem trying to implement generics.

[Marin David Condic]

I've been an on-and-off C programmer for a *lot* of years. I'm currently
doing nothing but C programming. I dislike the various C shorthand operators
and don't use them because it is not immediately and intuitively obvious to
even the most casual observer what it is they are doing. Most programmers
can recognize the basic algebraic notation that is common to almost all
popular programming languages (your basic "Y = M * X + B" type of thing) and
so I use that type of expression in (almost) all C programming contexts. (I
don't think I need to mention all the possible problems that come up in the
more clever uses of esoteric features like the difference between "++X" and
"X++" - but I guess I just did. People who use *that* kind of thing should
be turned into castrati so that they start singing a different tune. :-)

I've had the debate with various associates which usually starts out with
"Any *competent* C programmer should be able to....." My retort is always:
"How does it make me money when a less-than-"competent" C programmer has to
decypher it?" Every minute spent trying to figure out what an expression
does is a minute *not* spent making money for the stockholders. If there is
even the slightest possibility that someone can misinterpret what the
expression means or possibly get the syntax wrong or otherwise botch things
up, then it ought to be avoided. (Assuming one has a simpler, more obvious
representation for the same thing. After all, there are those who will have
trouble understanding "Y = M * X + B" but I'm not sure I can make it much
simpler for them. At least if they know some Fortran, Pascal, Ada, <insert
language here>, chances are they won't have much trouble guessing what that
sort of expression means in C.)

The "+=", et alia, were basically invented by people who couldn't type. I'd
rather opt for the clarity in the expression and not worry about all the
interesting ways of representing it in fewer keystrokes. After all, on any
given day of the week *I'm* not a "competent" C programmer! (Especially
before coffee in the AM!) I don't want to work that hard to understand what
I did yesterday when I was fully awake.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0104171057590.21817-100000@shell5.ba.best.com...
> > Of course, I also refused to use ++, --, +=, and all the other
> > wierd C operators.  Matter of taste, I guess.
>
> Indeed, some people have a problem adapting to the features of other
> languages.

Re: Problem trying to implement generics.

[Brian Rogoff]

On Tue, 17 Apr 2001, Marin David Condic wrote:
> I've been an on-and-off C programmer for a *lot* of years. I'm currently
> doing nothing but C programming. 

You have my condolences. 

> I dislike the various C shorthand operators and don't use them because
> it is not immediately and intuitively obvious to even the most casual 
> observer what it is they are doing. 

It's not obvious to the most casual observer what any program in any
programming language does, or what the meaning of a legal contract is, 
or whether a PDE is elliptic, parabolic, or hyperbolic, or the difference
between a pin and and x-ray attack in chess, etc. ad-infinitum,
ad-nauseum. 

Every good programmer who uses C will learn what those shorthand notations 
means. Other languages, even clean slate ones like Icon, have copied some
of those shorthands. I find them equally readable to Ada's long winded
expression. This is a bad example of a C problem. 

 Most programmers
> can recognize the basic algebraic notation that is common to almost all
> popular programming languages (your basic "Y = M * X + B" type of thing) and
> so I use that type of expression in (almost) all C programming contexts. (I
> don't think I need to mention all the possible problems that come up in the
> more clever uses of esoteric features like the difference between "++X" and
> "X++" - but I guess I just did. People who use *that* kind of thing should
> be turned into castrati so that they start singing a different tune. :-)

I agree that there's a fine line. But I'd prefer the shorthand line 

Some_Long_Variable_Name++; /* A C programmer would write slvd++ ;-) */

or even 

Incr(Some_Long_Variable_Name); -- how's this? 

or 

Incr(Some_Long_Variable_Name, Delta => Increment); 

to this 

Some_Long_Variable_Name := Some_Long_Variable_Name + 1;

and I think it makes sense in a programming language to have shorthand for 
very commonly occurring operations. 

For instance, I really wish some future Ada would add << and >> for bit
shifts. 

> I've had the debate with various associates which usually starts out with
> "Any *competent* C programmer should be able to....." My retort is always:
> "How does it make me money when a less-than-"competent" C programmer has to
> decypher it?" 

IMO, a good example of this is writing string or array traversals by
using pointer offsetting. Yuck! Using arrays is much clearer. 

> Every minute spent trying to figure out what an expression does is a
> minute *not* spent making money for the stockholders. 

Well, that's a good argument for removing floating point from most
programming languages too ;-). Please read some of William Kahan's work if 
you don't get the joke...

> even the slightest possibility that someone can misinterpret what the
> expression means or possibly get the syntax wrong or otherwise botch things
> up, then it ought to be avoided. (Assuming one has a simpler, more obvious
> representation for the same thing. After all, there are those who will have
> trouble understanding "Y = M * X + B" but I'm not sure I can make it much
> simpler for them. At least if they know some Fortran, Pascal, Ada, <insert
> language here>, chances are they won't have much trouble guessing what that
> sort of expression means in C.)

C is a different language from Fortran, Pascal, and Ada. I wouldn't hire
an Ada programmer who knew only the Ada/Pascal/Fortran/C intersection of 
features. I wouldn't hire a C programmer who refused to learn C, and
insisted on working in some pidgin Algol subset. 

> The "+=", et alia, were basically invented by people who couldn't type. I'd
> rather opt for the clarity in the expression and not worry about all the
> interesting ways of representing it in fewer keystrokes. After all, on any
> given day of the week *I'm* not a "competent" C programmer! 

I guess there must be something about Ada that makes people into very bad
C programmers. I wrote my first little C program in about a year a few
days ago, and I tripped up on the argc, argv indexing but not on the 
shorthand operators. Go figure.

> I don't want to work that hard to understand what
> I did yesterday when I was fully awake.

I'd find these anti-C arguments would be more compelling if I'd observed
these problems in my own C programs. I haven't. The most interesting
comments were on the lack of a matching lexeme for closing {} and
L. Guerby's comments on how C's semantics lead to debugging nightmares. 
Oh, I'd also say that flat languages (no nesting + lexical scope) suck. 
But C syntax and shorthand operators are not all bad. 

-- Brian

Re: Problem trying to implement generics.

[Chad R. Meiners]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message > and I think it
makes sense in a programming language to have shorthand for
> very commonly occurring operations.
>
> For instance, I really wish some future Ada would add << and >> for bit
> shifts.

Are bit shifts really a commonly occurring operation in Ada?  I can only
think of think of a handful of time I have needed to use them in my five
years of using Ada.

-Chad R. Meiners

Re: Problem trying to implement generics.

[Marin David Condic]

It seems to be a thing C programmers are more hung up on than is really
necessary. Certainly some domains use bit shifts more than others (writing
low level code for device drivers, etc., vs accounting software.) Even so, I
find there are really rather few times I've *needed* to do bit shifting -
usually there are other ways of accomplishing the same thing. I'm glad Ada
lets you do it, but I don't think it needs a more convenient operator. (One
*could* redefine ">" and "<" to yield bit shift results...) Besides, the <<
and >> symbols are used for labels to which one does a goto and there may be
some syntactic reason it would be tough to define them as operators. (I'd
really hate to have to retrofit all the thousands of lines of Ada code I
have that use labels in order to accommodate a new bit-shift operator. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:3addad93.0@silver.truman.edu...
> Are bit shifts really a commonly occurring operation in Ada?  I can only
> think of think of a handful of time I have needed to use them in my five
> years of using Ada.
>

Re: Problem trying to implement generics.

[chris.danx]

> The "+=", et alia, were basically invented by people who couldn't type.

Sorry but that's not correct.  I used to have a similar opinion, but i was
corrected by someone who, like me, dislikes C.  Anyways "+=" and "*=" are
deliberately written like this because of "structured assembly" which is
what C is meant to be.

Consider the following assembly (intel X86 style syntax) ,

ADD       A, B                          ;  add B to A

it's written in C like this

A += B;
(maybe B+=A;  I ain't used it myself so i don't know}

That's why it was designed this way and it was chosen by K & R delib.  The
language was invented to write OS's.  Not a very good attempt if you ask me,
it's left the world with buggy programs that need ton's of comments but
usually don't have because C programmers seem think it's clever not to
include them.  Most of my Ada code(and much of the Ada code out there) only
needs "what it does" in the spec with only the smallest amount of "how it
does it" in the body.  I also find that a lot more effort is needed to
explain C code in intro texts than Ada (I've got a few 100 to 400 page books
for Ada that cover quite a bit, but a 1000+ page book on C that doesn't
teach very much except "in C if a function screws up return a non-zero
integer")

[End of useless information...]

Chris.

Re: Problem trying to implement generics.

[chris.danx]

> The "+=", et alia, were basically invented by people who couldn't type.

Sorry but that's not correct.  I used to have a similar opinion, but i was
corrected by someone who, like me, dislikes C.  Anyways "+=" and "*=" are
deliberately written like this because of "structured assembly" which is
what C is meant to be.

Consider the following assembly (intel X86 style syntax) ,

ADD       A, B                          ;  add B to A

it's written in C like this

A += B;
(maybe B+=A;  I ain't used it myself so i don't know}

That's why it was designed this way and it was chosen by K & R delib.  The
language was invented to write OS's.  Not a very good attempt if you ask me,
it's left the world with buggy programs that need ton's of comments but
usually don't have because C programmers seem think it's clever not to
include them.  Most of my Ada code(and much of the Ada code out there) only
needs "what it does" in the spec with only the smallest amount of "how it
does it" in the body.  I also find that a lot more effort is needed to
explain C code in intro texts than Ada (I've got a few 100 to 400 page books
for Ada that cover quite a bit, but a 1000+ page book on C that doesn't
teach very much except "in C if a function screws up return a non-zero
integer")

[End of useless information...]

Chris.

Re: Problem trying to implement generics.

[chris.danx]

> The "+=", et alia, were basically invented by people who couldn't type.

Sorry but that's not correct.  I used to have a similar opinion, but i was
corrected by someone who, like me, dislikes C.  Anyways "+=" and "*=" are
deliberately written like this because of "structured assembly" which is
what C is meant to be.

Consider the following assembly (intel X86 style syntax) ,

ADD       A, B                          ;  add B to A

it's written in C like this

A += B;
(maybe B+=A;  I ain't used it myself so i don't know}

That's why it was designed this way and it was chosen by K & R delib.  The
language was invented to write OS's.  Not a very good attempt if you ask me,
it's left the world with buggy programs that need ton's of comments but
usually don't have because C programmers seem think it's clever not to
include them.  Most of my Ada code(and much of the Ada code out there) only
needs "what it does" in the spec with only the smallest amount of "how it
does it" in the body.  I also find that a lot more effort is needed to
explain C code in intro texts than Ada (I've got a few 100 to 400 page books
for Ada that cover quite a bit, but a 1000+ page book on C that doesn't
teach very much except "in C if a function screws up return a non-zero
integer")

[End of useless information...]

Chris.

Re: Problem trying to implement generics.

[Lao Xiao Hai]

Marin David Condic wrote:

> The "+=", et alia, were basically invented by people who couldn't type. I'd
> rather opt for the clarity in the expression and not worry about all the
> interesting ways of representing it in fewer keystrokes. After all, on any
> given day of the week *I'm* not a "competent" C programmer! (Especially
> before coffee in the AM!) I don't want to work that hard to understand what
> I did yesterday when I was fully awake.

Each language has its syntactical conventions and it is simply a matter of
becoming comfortable with them.    I have even encountered a few unusual
people who disliked vi. :-)         If my memory has not failed me, I seem to
recall that the +=, ++, and certain other shorthand constructs originate on
the platform for which C was originally designed, the PDP-11.    The same
is true of many other C syntactic novelties.

When incorporated into an object-oriented language such as C++ or Java,
these constructs cease to be novelties and become borderline pathological.
Certainly, they are anachronistic.    Then again, I am composing this message
on a QWERTY keyboard instead of the more efficient DVORAK keyboard.
Change comes hard, even when the change is clearly an improvement.  The
design of C# seems to have eliminated a few of the original pathologies, but
not all.

We each have our own criteria for what makes a good programming language.
I like a language where the compiler can maximize the amount of error detection
as early in the development process as possible.   For the most part, the C
family of languages fails that test.  I like a language where, at run-time, I
can
hope for minimal surprise.   The C family of languages fails that test.    Some
prefer a language that is popular.   The C family of languages will pass that
test.   Others prefer one that is quick to code quick to get executable
programs,
properly working or not.   The C family of languages does fairly well in that
category.

In recent years, with the advent of better tools, we can now develop Ada
programs as quickly as C or C++.   With graphical tools, we can build
GUI's that compare favorably to MSF or Java Bytecode.   So, when I also
say, I prefer a language that is highly portable,  Ada fulfills that need
quite nicely.   I can think of no good reason I would want to "take up arms
against a sea of troubles" and convert to any of the C family of languages.

Re: Problem trying to implement generics.

[John English]

Lao Xiao Hai wrote:
> If my memory has not failed me, I seem to
> recall that the +=, ++, and certain other shorthand constructs originate on
> the platform for which C was originally designed, the PDP-11.

A common myth, but in fact C was originally developed on the PDP-7.
See http://burks.bton.ac.uk/burks/pcinfo/history/lucent/chist.htm
for the full story.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Problem trying to implement generics.

[Lao Xiao Hai]

John English wrote:

> Lao Xiao Hai wrote:
> > If my memory has not failed me, I seem to
> > recall that the +=, ++, and certain other shorthand constructs originate on
> > the platform for which C was originally designed, the PDP-11.
>
> A common myth, but in fact C was originally developed on the PDP-7.
> See http://burks.bton.ac.uk/burks/pcinfo/history/lucent/chist.htm
> for the full story.

Thanks John.   I knew it was one of the PDP- series.   The first one I got to
work
on was the PDP-8, a rather interesting and strange machine with a twelve-bit
word.   The only available language at that time was Assembler.   Maybe we
would have been happy to have C.

Richard Riehle

Re: Problem trying to implement generics.

[Larry Hazel]

Brian Rogoff wrote:
> 
> On Tue, 17 Apr 2001, Larry Hazel wrote:
> > Ayende Rahien wrote:
> > >
> > > "Tucker Taft" <stt@averstar.com> wrote in message
> > > news:3ADC4320.7ACA3DEC@averstar.com...
> > >
> > > > Interestingly enough, the standard Iterator in Java
> > > > uses:
> > > >      while (Iter.hasNext()) {
> > > >          X = Iter.next();
> > > >          ...
> > > >      }
> > > >
> > > > even though Java has functions with side effects (although
> > > > in fact, only with side-effects on by-reference operands,
> > > > since it has no parameter modes at all!).
> > >
> > > Why use it like this?
> > > for (;Iter.hasNext(); X = Iter.next() ){
> > >     //do stuff
> > > }
> > >
> > > Is much more readable, IMO.
> >
> > I disagree.  The C style for loop is totally unreadable garbage IMO.
> 
> Well, to a C programmer the for loop is perfectly readable. As someone
> familiar with C, Java, Ada, and a few other languages, I have to say that
> I found Tucker's original expression far preferable to Ayende's,
> though I'd prefer "hasMore" to "hasNext" :-). Ayende, why do you find the
> for loop preferable in this case?
> 
> As long as we're considering iterators, it should be mentioned that
> iterators are one of the great examples for adding downward funargs into
> the language.
> 
> > In what little C programming I have done, I refused to use for loops.
> 
> Did you use macros to set { and } to BEGIN and END too?
> 
I thought about it, but just commented the } instead.

Larry

Re: Problem trying to implement generics.

[Ayende Rahien]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0104171057590.21817-100000@shell5.ba.best.com...
> On Tue, 17 Apr 2001, Larry Hazel wrote:
> > Ayende Rahien wrote:
> > >
> > > "Tucker Taft" <stt@averstar.com> wrote in message
> > > news:3ADC4320.7ACA3DEC@averstar.com...
> > >
> > > > Interestingly enough, the standard Iterator in Java
> > > > uses:
> > > >      while (Iter.hasNext()) {
> > > >          X = Iter.next();
> > > >          ...
> > > >      }
> > > >
> > > > even though Java has functions with side effects (although
> > > > in fact, only with side-effects on by-reference operands,
> > > > since it has no parameter modes at all!).
> > >
> > > Why use it like this?
> > > for (;Iter.hasNext(); X = Iter.next() ){
> > >     //do stuff
> > > }
> > >
> > > Is much more readable, IMO.
> >
> > I disagree.  The C style for loop is totally unreadable garbage IMO.
>
> Well, to a C programmer the for loop is perfectly readable. As someone
> familiar with C, Java, Ada, and a few other languages, I have to say that
> I found Tucker's original expression far preferable to Ayende's,
> though I'd prefer "hasMore" to "hasNext" :-). Ayende, why do you find the
> for loop preferable in this case?

Because it iterate, which is the whole point of the for loop.
In this case, the code that decide how many times the loop will loop is on
one line, and easy to see & understand.
The part that does stuff is seperated from the looping part, which makes for
easier reading.
I tend to use the for loop whenever I've something that can be broken like
this (checking & forwarding).

> As long as we're considering iterators, it should be mentioned that
> iterators are one of the great examples for adding downward funargs into
> the language.

What is funargs?

> > In what little C programming I have done, I refused to use for loops.
>
> Did you use macros to set { and } to BEGIN and END too?
>
> > Of course, I also refused to use ++, --, +=, and all the other
> > wierd C operators.  Matter of taste, I guess.
>
> Indeed, some people have a problem adapting to the features of other
> languages.

In C's case, those stuff may reduce readiabilty to those who are unfamiliar
with the language, but they make for smaller code.
Of course, you can always overdo it and turn a sentece to incomprehincible
mess, which some people take advantage of.
I recall once having to read (my own, written couple of days ago) a 260
characters of C++ code which took over an fifteen minutes to comprehend.
IIRC, it was copying one matrix to the other.

Re: Problem trying to implement generics.

[Brian Rogoff]

On Tue, 17 Apr 2001, Ayende Rahien wrote:
> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > On Tue, 17 Apr 2001, Larry Hazel wrote:
> > > Ayende Rahien wrote:
> > > >
> > > > Why use it like this?
> > > > for (;Iter.hasNext(); X = Iter.next() ){
> > > >     //do stuff
> > > > }
> > > >
> > > > Is much more readable, IMO.
> > >
> > > I disagree.  The C style for loop is totally unreadable garbage IMO.
> >
> > Well, to a C programmer the for loop is perfectly readable. As someone
> > familiar with C, Java, Ada, and a few other languages, I have to say that
> > I found Tucker's original expression far preferable to Ayende's,
> > though I'd prefer "hasMore" to "hasNext" :-). Ayende, why do you find the
> > for loop preferable in this case?
> 
> Because it iterate, which is the whole point of the for loop.

What's the point of the while loop? No, don't answer that, or this thread
will loop on and on :-). 

Suffice to say, I disagree. The following is fine

while (iter.hasMore()) {
  X := iter.getNext();
  // do stuff with X
} while; // optional :-)

> In this case, the code that decide how many times the loop will loop is on
> one line, and easy to see & understand.
> The part that does stuff is seperated from the looping part, which makes for
> easier reading.
> I tend to use the for loop whenever I've something that can be broken like
> this (checking & forwarding).

I tend to use it for traversing arrays. I think of a lot of these
iterators as data sources. If you don't know how long a data source is 
then it makes more sense to query for the data; if I were to express the
operation in (American) English, my favorite programming language, I'd say

    "While this data source has data, do the followings : do some
    stuff, take the next data item out, do some more stuff, and then start 
    over. 

> > As long as we're considering iterators, it should be mentioned that
> > iterators are one of the great examples for adding downward funargs into
> > the language.
> 
> What is funargs?

Functions as arguments. There are now funargs in Ada but they are C level 
function pointers. Personally I'd love to see downward and even anonymous 
funargs in Ada but I suspect it'll never happen. At some point in your
programming career you'll have to program in a functional language
(a Haskell or a Clean, or an ML like OCaml or SML, or even a Lisp) and 
if you do it enough you get used to programming with functions as first
class data objects. 

> > Indeed, some people have a problem adapting to the features of other
> > languages.
> 
> In C's case, those stuff may reduce readiabilty to those who are unfamiliar
> with the language, but they make for smaller code.
> Of course, you can always overdo it and turn a sentece to incomprehincible
> mess, which some people take advantage of.
> I recall once having to read (my own, written couple of days ago) a 260
> characters of C++ code which took over an fifteen minutes to comprehend.
> IIRC, it was copying one matrix to the other.

As soon as I saw Ada it crystallized a lot of my thoughts on proper C
style and I haven't been bitten by evil C in my own code for a while. 
Two simple things to help with your C: 

(1) Don't do flashy pointer indexing and use of ++ on pointers to traverse 
    arrays. This is one of those tests they give to C programmers about
    writing strcmp using a pointer increment and checking for the null 
    at the end of the string. Horrible. I'd write similar code using array 
    notation and a for loop.

(2) Don't use ++, +=, ... inside array indexings, function calls, etc. 
    Just put them in a for loop or as independent actions on their own
    lines. 

Also, let me recommend that you pick up a copy of Hanson's "C Interfaces
and Implementations" so that you start applying good style to your C. I'm 
actually a firm believer in writing Ada-like C code, but that doesn't mean 
"twist C surface syntax to look like Ada" but rather "apply the
principles of SW engineering embodied in Ada to write C with interface and 
implementation well separated". 

-- Brian

Re: Problem trying to implement generics.

[Georg Bauhaus]

Brian Rogoff (bpr@shell5.ba.best.com) wrote:

: Suffice to say, I disagree. The following is fine

: while (iter.hasMore()) {
:   X := iter.getNext();
:   // do stuff with X
: } while; // optional :-)

Yes, really fine. I've just run the equivalent of

  int c = 0;
  while (c < 1000) {
    c += 2;
  } while (0);

through C and Java compilers (HP/GNU/IBM). What fun!
The code produced is the same irrespective of this nice
C "end while" construct :-)  So the brackets vs. begin/end
discussion is OBE?

Re: Problem trying to implement generics.

[Lutz Donnerhacke]

* Georg Bauhaus wrote:
>  while (c < 1000) {
>    c += 2;
>  } while (0);

;-)

 while (c < 1000) {
   c += 2;
 } while (1);

ist much better. It won't termine.

Re: Problem trying to implement generics.

[Lutz Donnerhacke]

* Georg Bauhaus wrote:
>  while (c < 1000) {
>    c += 2;
>  } while (0);

;-)

 while (c < 1000) {
   c += 2;
 } while (1);

ist much better. It won't terminate.

Re: Problem trying to implement generics.

[Brian Rogoff]

On Fri, 20 Apr 2001, Georg Bauhaus wrote:
> Brian Rogoff (bpr@shell5.ba.best.com) wrote:
> 
> : Suffice to say, I disagree. The following is fine
> 
> : while (iter.hasMore()) {
> :   X := iter.getNext();
> :   // do stuff with X
> : } while; // optional :-)
> 
> Yes, really fine. I've just run the equivalent of
> 
>   int c = 0;
>   while (c < 1000) {
>     c += 2;
>   } while (0);
> 
> through C and Java compilers (HP/GNU/IBM). What fun!

Interesting. 

> The code produced is the same irrespective of this nice
> C "end while" construct :-)  So the brackets vs. begin/end
> discussion is OBE?

Well, the whole thing is somewhat whimsical. I personally prefer this
aspect of Ada syntax but it's very, very low on my list, so if I were 
voting on some new language design I'd probably vote to keep begin-end 
but if the rest of the world wants {} instead so be it. 

I'd really like to use the {} for something else, and there are only a few 
symmetric bracket pairs to choose from. 

-- Brian

Re: Problem trying to implement generics.

[David Starner]

On Fri, 20 Apr 2001 19:48:05 GMT, Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> I'd really like to use the {} for something else, and there are only a few 
> symmetric bracket pairs to choose from. 

In ASCII, maybe. In Unicode, I count at least 12 pairs. Of course, going 
the APL route may not be the best solution for a new language . . .

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Problem trying to implement generics.

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> Well, the whole thing is somewhat whimsical. I personally prefer this
> aspect of Ada syntax but it's very, very low on my list, so if I were 
> voting on some new language design I'd probably vote to keep begin-end 
> but if the rest of the world wants {} instead so be it. 

I agree that it's not the most important thing.

One thing I've considered is having two alternate syntaxes for the
various control structures.  For example, you could say:

    if Condition then
        ...
    end if;

or

    if Condition { ... };

or something like that.  The former would be used when "..." is long;
the latter when "..." is short (eg three lines or less?) -- so short
that the "}" is close to the "if", so it's obvious what it belongs to,
so "end if" is merely clutter in that case.

And probably the {...} syntax couldn't have other control structures
nested inside it -- it's only allowed for the innermost thing.

Good idea?

Oh, and I'd like my editor to automatically convert from one to the
other as "..." grows or shrinks.

> I'd really like to use the {} for something else, and there are only a few 
> symmetric bracket pairs to choose from. 

What did you have in mind?  Literals of type "set"?

Note that you can invent new bracket-y pairs using some slightly ugly
syntax like:

    (.   .)
    (:   :)
    (*   *) -- Pascal uses this one.
    <<   >> -- Ada uses this one.
    ``   '' -- The TeX "programming" language uses this. ;-)

BTW, I wish ASCII had left and right double-quote characters.  That
would be much more civilized.

- Bob

Re: Problem trying to implement generics.

[Brian Rogoff]

On Fri, 20 Apr 2001, Robert A Duff wrote:
> One thing I've considered is having two alternate syntaxes for the
> various control structures.  For example, you could say:
> 
>     if Condition then
>         ...
>     end if;
> 
> or
> 
>     if Condition { ... };
> 
> or something like that.  The former would be used when "..." is long;
> the latter when "..." is short (eg three lines or less?) -- so short
> that the "}" is close to the "if", so it's obvious what it belongs to,
> so "end if" is merely clutter in that case.

How about just using the {} and having an optional } if; syntax? 

> And probably the {...} syntax couldn't have other control structures
> nested inside it -- it's only allowed for the innermost thing.
> 
> Good idea?

I don't like it. 

> Oh, and I'd like my editor to automatically convert from one to the
> other as "..." grows or shrinks.

At this point, I say adopt indentation for block structure. 

> > I'd really like to use the {} for something else, and there are only a few 
> > symmetric bracket pairs to choose from. 
> 
> What did you have in mind?  Literals of type "set"?

Actually, I was thinking of a more lightweight genericity than what Ada
has now and actually using the {} like C++ uses <> and Eiffel uses 
[].  

> Note that you can invent new bracket-y pairs using some slightly ugly
> syntax like:
> 
>     (.   .)
>     (:   :)

Ever seen BETA? It does that kind of stuff, and uses (for for), (if if) 
kinds of bracketing pairs. 

>     (*   *) -- Pascal uses this one.

It's the source of a syntax bug in OCaml, let (*) x y = mult x y fails :-). 

>     <<   >> -- Ada uses this one.
>     ``   '' -- The TeX "programming" language uses this. ;-)

Funny you mentioned that, I've started using LaTeX again. Sometimes the
old ways are better :-).

> BTW, I wish ASCII had left and right double-quote characters.  That
> would be much more civilized.

Oh well. Maybe the decision to restrict a language to ASCII will be viewed
in the future like Ada's current restrictions. There are certainly glyphs 
that I'd use if I could but I think ASCII is a fair restriction for the 
lexemes of the surface syntax of a language. 

-- Brian

Re: Problem trying to implement generics.

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> How about just using the {} and having an optional } if; syntax? 

I suppose it's just a matter of taste, but I find "} if;" distasteful.

> > And probably the {...} syntax couldn't have other control structures
> > nested inside it -- it's only allowed for the innermost thing.
> > 
> > Good idea?
> 
> I don't like it. 

Why?

> > Oh, and I'd like my editor to automatically convert from one to the
> > other as "..." grows or shrinks.
> 
> At this point, I say adopt indentation for block structure. 

But indentation only marks the *beginning* of the thing.

> Funny you mentioned that, I've started using LaTeX again. Sometimes the
> old ways are better :-).

It amazes me that Knuth, who is orders of magnitude smarter than me, can
design such an awful language.  Writing TeX is like writing an
assembly-language program to generate a document.  Except TeX is more
error-prone than most assembly languages.  LaTeX is like programming in
a *macro* assembly language, which has some advantages, but causes all
error messages to be totally incomprehensible.

> > BTW, I wish ASCII had left and right double-quote characters.  That
> > would be much more civilized.
> 
> Oh well. Maybe the decision to restrict a language to ASCII will be viewed
> in the future like Ada's current restrictions. There are certainly glyphs 
> that I'd use if I could but I think ASCII is a fair restriction for the 
> lexemes of the surface syntax of a language. 

Sigh.  Maybe when Unicode is uniformly supported by all hardware and
software...

- Bob

Re: Problem trying to implement generics.

[Brian Rogoff]

On Tue, 24 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > How about just using the {} and having an optional } if; syntax? 
> 
> I suppose it's just a matter of taste, but I find "} if;" distasteful.

I was trying to capture the readability of the Ada end ...; constructions,
which I miss in other languages, with some suitability as a very
lightweight delimiter, useable even with inline function definitions. 
Could be an overconstrained problem.

> > > And probably the {...} syntax couldn't have other control structures
> > > nested inside it -- it's only allowed for the innermost thing.
> > > 
> > > Good idea?
> > 
> > I don't like it. 
> 
> Why?

I generally don't like fairly arbitrary restrictions like that one. Why
not allow nesting {}? I have philosophically similar objections to
automatically "use"ing infix operators. I prefer to handle operators like 
other functions. 

> > > Oh, and I'd like my editor to automatically convert from one to the
> > > other as "..." grows or shrinks.
> > 
> > At this point, I say adopt indentation for block structure. 
> 
> But indentation only marks the *beginning* of the thing.
> 
> > Funny you mentioned that, I've started using LaTeX again. Sometimes the
> > old ways are better :-).
> 
> It amazes me that Knuth, who is orders of magnitude smarter than me, can
> design such an awful language.

Language design is a skill, and just becuase someone excels in some subset
of talents doesn't necessarily mean they are skilled everywhere. Remember, 
Knuth still uses a mock assembly language to describe algorithms in this 
books. Yuck!

I agree TeX and LaTeX suck as languages, but the TeX program is very cool
and I really prefer it to may of the WYSIWYG tools I suffered through
before my return to the LaTeX fold. 

> Writing TeX is like writing an
> assembly-language program to generate a document.  Except TeX is more
> error-prone than most assembly languages.  LaTeX is like programming in
> a *macro* assembly language, which has some advantages, but causes all
> error messages to be totally incomprehensible.

That's all true, and I'd probably use Lout but for all of the other
reasons we use a piece of software. Besides, I much prefer it to the
commercial offerings. 

-- Brian

Re: Problem trying to implement generics.

[Georg Bauhaus]

Brian Rogoff (bpr@shell5.ba.best.com) wrote:
: On Tue, 24 Apr 2001, Robert A Duff wrote:
: > Brian Rogoff <bpr@shell5.ba.best.com> writes:
: > 
: > > How about just using the {} and having an optional } if; syntax? 
: > 
: > I suppose it's just a matter of taste, but I find "} if;" distasteful.

: I was trying to capture the readability of the Ada end ...; constructions,
: which I miss in other languages, with some suitability as a very
: lightweight delimiter, useable even with inline function definitions. 
: Could be an overconstrained problem.

Isn't there a parsing issue, i.e. knowing whether a spurious }
belongs to, well, _some_ {, or "end if" belonging to "if", not
while say?


Georg

Re: Problem trying to implement generics.

[Georg Bauhaus]

Robert A Duff (bobduff@world.std.com) wrote:

: It amazes me that Knuth, who is orders of magnitude smarter than me, can
: design such an awful language.  Writing TeX is like writing an
: assembly-language program to generate a document.  Except TeX is more
: error-prone than most assembly languages.  LaTeX is like programming in
: a *macro* assembly language, which has some advantages, but causes all
: error messages to be totally incomprehensible.

The answer to this is, according to some recent publication of his,
is that TeX was to be a _backend_ much in the sense of macro assembly.
He writes that Steele urged him to add more "control structures".

If you are interested in a more Algol-like formatting language
(that uses TeX's paragraph breaking and more), Lout might be a choice.
It has a component, prg2lout, for include source code in documents,
with support for C, Eiffel, Python, and Perl; I've fiddled with adding
Ada support, and this has been fairly easy.  You can refer to
Ada code in comments by quoting it.

ftp://ftp.cs.usyd.edu.au/jeff/lout/
http://snark.ptc.spbu.ru/~uwe/lout/


Georg

Re: Problem trying to implement generics.

[Marius Amado Alves]

> : ...  LaTeX is like programming in a *macro* assembly language,
> ... TeX was to be a _backend_ much in the sense of macro assembly.

There should be no surprise here.  LaTeX _is_ a macro language, and TeX
_is_ assembler. Now, yes: they were both overloaded beyond reason with
dreadful syntactic devices.  Fortunately today we have XML ;-)

-- 
Marius Amado Alves
 alves@systran.lu
Project Tradaut-Pt
Systran Luxembourg
12, Rue de Vianden
L-2680  LUXEMBOURG
Tel 352 + 45 46 53
Fax 352 + 45 74 75
Mob 351 +939354002

Re: Problem trying to implement generics.

[Larry Kilgallen]

In article <9bkfk4$6a2$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> It seems to be a thing C programmers are more hung up on than is really
> necessary. Certainly some domains use bit shifts more than others (writing
> low level code for device drivers, etc., vs accounting software.)

Thinking about device drivers I have written (not in C or Ada) it seems
to me that bit shifting is most likely to be the "manual" operation used
in low-level languages where the conceptually desired operation is not
supported.

For instance, if one has a numeric field that is supposed to be
positioned three bits left in a register the low-level approach
(at the source level) would be to "shift" and "or" it together
with the other bits before setting it into the register.

The conceptual operation is to store a field into a register-format
record before setting it into a record.  The Ada method is much
more logical, except for those with lots of experience writing
drivers in lesser languages.

Re: Problem trying to implement generics.

[Marin David Condic]

Most of the conditions in which I've seen people doing bitwise operations
(shifts, xors, etc.) seem to be handled in Ada by proper use of
representation clauses. You create records that match the bit layout of
registers or packed arrays of boolean & similar things. Unless the Ada
implementation of access to these fields is pathetically slow, it usually is
going to handle things much more cleanly. Need a three bit integer from the
center of a machine word? Put it in a rep claused record and just use
assignment!

Still, its handy to have the logical operations. One really great use I had
for them was when reading/writing various A/D and Discrete values from
hardware. By always doing an XOR of the input with a constant in memory, you
could plug the constant at runtime with a monitor program and toggle the
input bits. This was invaluable for testing. (Same trick works with always
adding a constant to a mathematical input - "tuning" constants, as it were.)
So having logical operations is very useful in many spots. But I think
you're right about them being used to compensate for a lack of language
facilities in most cases.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:YlSyXUaQmD+$@eisner.encompasserve.org...
> In article <9bkfk4$6a2$1@nh.pace.co.uk>, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> writes:
>
> Thinking about device drivers I have written (not in C or Ada) it seems
> to me that bit shifting is most likely to be the "manual" operation used
> in low-level languages where the conceptually desired operation is not
> supported.
>
> For instance, if one has a numeric field that is supposed to be
> positioned three bits left in a register the low-level approach
> (at the source level) would be to "shift" and "or" it together
> with the other bits before setting it into the register.
>
> The conceptual operation is to store a field into a register-format
> record before setting it into a record.  The Ada method is much
> more logical, except for those with lots of experience writing
> drivers in lesser languages.

Re: Problem trying to implement generics.

[Mike Silva]

Just to add another IMO, I've been writing (and debugging!!!) C for over 20
years, and C++ for almost half that time, and I think the for() loop version
below is just the kind of gimmick that can make C/C++ code so hard for a
programmer-reader to grasp, and if I came across it I'd be sorely tempted to
move the function calls (-especially- the assignment to X) out of the for()
for readability alone.

Mike

"Ayende Rahien" <Dont@spam.me> wrote in message
news:9bhoup$h9k$1@taliesin.netcom.net.uk...
>
> "Tucker Taft" <stt@averstar.com> wrote in message
> news:3ADC4320.7ACA3DEC@averstar.com...
>
> > Interestingly enough, the standard Iterator in Java
> > uses:
> >      while (Iter.hasNext()) {
> >          X = Iter.next();
> >          ...
> >      }
> >
> > even though Java has functions with side effects (although
> > in fact, only with side-effects on by-reference operands,
> > since it has no parameter modes at all!).
>
> Why use it like this?
> for (;Iter.hasNext(); X = Iter.next() ){
>     //do stuff
> }
>
> Is much more readable, IMO.
>
>
>

Re: Problem trying to implement generics.

[Ray Blaak]

"Ayende Rahien" <Dont@spam.me> writes:
> "Tucker Taft" <stt@averstar.com> wrote in message
> > Interestingly enough, the standard Iterator in Java
> > uses:
> >      while (Iter.hasNext()) {
> >          X = Iter.next();
> >          ...
> >      }
> Why [not] use it like this?
> for (;Iter.hasNext(); X = Iter.next() ){
>     //do stuff
> }
> 
> Is much more readable, IMO.

Because that is wrong :-).

With the above for loop, the nth iteration has the value for iteration
n-1. The first iteration has no value at all. I.e. it is equivalent to:

  while(Iter.hasNext())
  { // ...do stuff with X...
    X = Iter.next();    
  }

The .next() method returns the current value and sets the iterator to be at
the next one. It does not return the next value per se.

A correct for loop is:

  for(; Iter.hasNext(); )
  { X = Iter.next();
    // ...do stuff with X...
  }

but that is redundant, so a while loop is better.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Problem trying to implement generics.

[Tucker Taft]

Ayende Rahien wrote:
> 
> "Tucker Taft" <stt@averstar.com> wrote in message
> news:3ADC4320.7ACA3DEC@averstar.com...
> 
> > Interestingly enough, the standard Iterator in Java
> > uses:
> >      while (Iter.hasNext()) {
> >          X = Iter.next();
> >          ...
> >      }
> >
> > even though Java has functions with side effects (although
> > in fact, only with side-effects on by-reference operands,
> > since it has no parameter modes at all!).
> 
> Why use it like this?
> for (;Iter.hasNext(); X = Iter.next() ){
>     //do stuff
> }
> 
> Is much more readable, IMO.

Well this started a long series of responses...  But the
key thing to point out is that the for-loop doesn't work.
You are assigning X a value too late to use it inside
the first iteration of the loop.  The third "part" of a for-loop
header is only executed at the *end* of each loop iteration.

When programming in C (or Java), I generally do use a
"for" loop when it works, but this is one case where it
definitely doesn't.

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: Problem trying to implement generics.

[Andy]

Ayende Rahien wrote:
> 
> I've just started to learn Ada, and I've some problem solving some problems.
> 
> Here is the spec I'm trying to compile:
> 
> with Ada.Finalization;
> generic
>  type data_type is private;
>  type Sort_by is private;
> package Binary_Trees is
>  type binary_Tree is new Ada.Finalization.controlled with private;
>  
  [snip]
>
> end Binary_Trees;
> 
> I trying to put the defination of Node in the body, but it results in
> compilation error, is there some way to put the defination in the body? Or
> does it matter naught, because it's on the private part of the package?
> 
> Since it's a binary tree, I've to have > working on all types that sort_by
> work on.
> How do I force it?
> At the moment, I've three compilation errors when I'm trying to use > on
> sort_by data.
> Here is the error:
> bintree.adb: Error: line 43 col 25 LRM:8.4(1), Binary operator ">" between
> Sort_by and Sort_by not directly visible, use clause or conversion might be
> needed

Ayende,
Expect you need something like this:
 
generic
  type data_type is private;
  type Sort_by is private;
  with function "<" (Left, Right: in Sort_By) return Boolean;
package Binary_Trees is

   -- as before

end Binary_Trees;

-- 
Regards,
Andy

Re: Problem trying to implement generics.

[Simon Wright]

Andy <startrek.nospam@ozonline.com.au> writes:

> generic
>   type data_type is private;
>   type Sort_by is private;
>   with function "<" (Left, Right: in Sort_By) return Boolean;

I would write

  with function "<" (Left, Right: in Sort_By) return Boolean is <>;

so that if a "<" is visible at the instantiation point it can be used
without explicitly saying so.

On the other hand, when doing the instantiation I probably would
specify the "<" explicitly!

-S

Re: Problem trying to implement generics.

[Ayende Rahien]

"Andy" <startrek.nospam@ozonline.com.au> wrote in message
news:3AD5B43F.6A5B@ozonline.com.au...


> Ayende,
> Expect you need something like this:
>
> generic
>   type data_type is private;
>   type Sort_by is private;
>   with function "<" (Left, Right: in Sort_By) return Boolean;
> package Binary_Trees is
>
>    -- as before
>
> end Binary_Trees;

Yes, that worked, thanks.

Re: Problem trying to implement generics.

[Stephen Leake]

"Ayende Rahien" <Dont@spam.me> writes:

> I've just started to learn Ada, and I've some problem solving some problems.

Congratulations; you are learning the best language around :).

> 
> 
> Here is the spec I'm trying to compile:
> 
> with Ada.Finalization;
> generic
>  type data_type is private;
>  type Sort_by is private;

This is part of your problem. A private type does not have ">"
defined, so you can't use ">" in the body of this package (that
explains one of the compiler errors). You have a couple choices:

1) change this to "type Sort_by is new integer"

This is ok, but not very flexible. Suppose you want to sort by
strings?

2) Replace with a function:

with function Greater_Than (Left, Right : in Data_Type) return
Boolean;

Now, in the body, call "Greater_Than (Data_1, Data_2)".

> package Binary_Trees is
>  type binary_Tree is new Ada.Finalization.controlled with private;
>  type node is private;
>  type node_access is access all Node;
>  type data_access is access all Data_type;
>  procedure insert(insert_this : in data_type; Sort : in sort_by);
>  --Insert into the binary tree, sort according to sort.
>  function Delete(Delete_this: in Sort_by; Index : in natural := 1) return
> boolean;
>  -- Delete a node from the tree, return true if succeeded, return false if
>  -- the node does not exist.
>  function Get(Search_For: in sort_by; index : in natural := 1) return
> data_access;
>  -- Search for nodes with duplicate sort_by variable. It find the first
>  -- node with the sort_by equal to the given one, and then continue to check
> for Index
>  -- number of duplicated. It return null if it there isn't a suitable node
> in the
>  -- correct index.
>  private
>   type Binary_Tree is new Ada.Finalization.controlled with record
>    root: Node_access := null;
>   end record;
>   type node is record
>    Data : Data_type;
>    Sorted_by: Sort_by;
>    Parent, Left, right : Node_access;
>   end record;
>      procedure Adjust(Object : in out Binary_Tree );
>      procedure Finalize(Object : in out Binary_Tree );
> end Binary_Trees;
> 
> I trying to put the defination of Node in the body, but it results in
> compilation error, is there some way to put the defination in the
> body? 

Yes; you use an "incomplete type declaration":

   package A_Package is
   private
      type Node_Type;
      type Node_Access_Type is access all Node_Type;
   end A_Package;

   package body A_Package is
      type Node_Type is record
         A : Integer;
      end record;
   end A_Package;

Note that the incomplete type must be declared in the private part.
Since you are referencing Node_Type in functions in the public part,
this won't work for you.


> does it matter naught, because it's on the private part of the
> package?
 
Users cannot see the "insides" of Node, so you still have data hiding
and abstraction. Moving Node to the body would let you change its
"insides" without recompiling. Sometimes that is important in a large
project; not here.


You could probably benefit from a good example; see my binary tree
package at 

http://users.erols.com/leakstan/Stephe/Ada/sal.html

But don't give up on yours; making your own binary tree is a good way
to learn!

<snipped the rest> 

-- 
-- Stephe