Re: Newbie question about generic linked list tasks

Re: Newbie question about generic linked list tasks

[Bob Kitzberger]

I (rlk@rational.com) wrote some drivel:

: 	generic
: 	  type Element ...
: 	package List_Generic is
: 	  type List is private;
: 	  ...
: 	end;
...
: 	package body List_Generic is
: 	  task Access_Control is
: 	    entry Start_Reader ...;
...
: 	  end Access_Control;


This is an example of what happens when firing off an answer before
thinking it through (and yes, I had my morning coffee, so I can't
use that as an excuse ;-)

This solution will technically work, but will serialize access across
all List objects for a particular List_Generic instantiation... when what
is desired is serialized access to a particular List object.  This implies
the need for one task per List object, rather than one task per List_Generic
instantiation.

Egg on my face... see Robert Eachus' solution for a better approach.

	.Bob.

--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945

Re: Newbie question about generic linked list tasks

[Robert I. Eachus]

In article <farrell.780237190@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:

  > I would like more concurrency than just semaphores gives you.

   Hmmm... The semaphores don't "grant" concurrency, they just allow
constructs to remain consistant even if concurrency is present.  In
constructing a concurrent application, you have to decide which
threads should be active, and which can be passive.  Usually lists are
treated as passive.  But that is another topic.

  >   Which is the important Booch book? I have Software Engineering
  > with Ada here, and it doesn't seem to say anything outstanding.

   I have it here too, and he has a companion book to the components,
but the components are purchased from Grady as source files.

 >   OK, I figured all this out by myself. But say I want to implement
 > list concatenation, how can I write an entry which takes an
 > argument of type List, so I could write:

 >   A.Concat(B);

 > In my experience it's not even possible to write the type...

   See Norm's answer on this.  But actually, if you make the task type
a (limited) private type, then it is possible to declare the operation
Concat(A,B) in a way that works.  However, to implement it...

 >    And what if I wanted to do a list traversal? I would have to
 > pass a procedure/function to operate on items as a generic, but I
 > don't believe I can pass them into an entry, so they would have to
 > be generic for the package.  Then I only have one traversal
 > function for each instantiation of the package?

   ...you will need primitive (and hidden) entries to the task type to
give you a handle into the list, and operations on it, say:

   entry Get_Handle(H: out Handle);
   entry Free_Handle(H: in out Handle);
   entry Next(H: in out Handle; I: out Item);
   entry At_End(H: in Handle; Done: out Boolean);

   (At_End is provided, but you would probably want to depend on Next
raising an exception at the end of the list.)  Now your list package
can export a generic traversal operation which takes a generic formal
procedure parameter.  If you code it right, you can even have several
traversals of the same list in progress at the same time.  If you
really want to do that, you might want two generic traversals, one
which allows only read access to list elements, and one which provides
read/write:

    generic
      with procedure Apply(I: in out Item);
    procedure Traverse(L: in out List);

    generic
      with procedure Look(I: in Item);
    procedure Walk(L: in out List);
 
 > What do you mean by completion?

   The full declaration which conforms to the private type declaration
and completes it.

 >   OK, that's nicer but I think there are still some ugly things. Thanks for
 > helping out with this, but my problems run deeper :-).

    Hope the above helps.  It is possible to do what you want in Ada
83, but the private part of the package (and the body!) start getting
messy.  If you get too fancy, you end up writing the body of the task
type as a finite state machine, with eight or nine accept statements
or altenatives for each entry.  (I know, I've done it, and multi-page
task bodies are a bitch to test.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Newbie question about generic linked list tasks

[John Farrell]

In <EACHUS.94Sep23105307@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article <farrell.780237190@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:
>  > I would like more concurrency than just semaphores gives you.
>   Hmmm... The semaphores don't "grant" concurrency, they just allow
>constructs to remain consistant even if concurrency is present.  In
>constructing a concurrent application, you have to decide which
>threads should be active, and which can be passive.  Usually lists are
>treated as passive.  But that is another topic.

  Well, it's an interesting topic to me. Active lists sound like fun. I got
the implementation with the binary semaphores working, only to discover that
after I had created a couple of hundred lists I reached a task limit :-(.
I spent two hours searching books saying "TASKING_ERROR, there can't be a
TASKING_ERROR in there!".

>>    And what if I wanted to do a list traversal? I would have to
>> pass a procedure/function to operate on items as a generic, but I
>> don't believe I can pass them into an entry, so they would have to
>> be generic for the package.  Then I only have one traversal
>> function for each instantiation of the package?

>   ...you will need primitive (and hidden) entries to the task type to
>give you a handle into the list, and operations on it, say:
>   entry Get_Handle(H: out Handle);
>   entry Free_Handle(H: in out Handle);
>   entry Next(H: in out Handle; I: out Item);
>   entry At_End(H: in Handle; Done: out Boolean);
>   (At_End is provided, but you would probably want to depend on Next
>raising an exception at the end of the list.)  Now your list package
>can export a generic traversal operation which takes a generic formal
>procedure parameter.  If you code it right, you can even have several
>traversals of the same list in progress at the same time.  

  So while I have a handle on the list, nothing else can access it? Hmmm, no,
while I have a handle on the list, no other task which started access after I
did can modify the current element or any later element. Cool!

>If you
>really want to do that, you might want two generic traversals, one
>which allows only read access to list elements, and one which provides
>read/write:

  Yep, my current package has a traverse procedure which applies a procedure
taking an in out to each element, and a traverse function which makes a new
list gotten by applying the function to each element.

> > What do you mean by completion?
>   The full declaration which conforms to the private type declaration
>and completes it.

  Ta.

>    Hope the above helps.  

  Yes, I'm inspired.

>It is possible to do what you want in Ada
>83, but the private part of the package (and the body!) start getting
>messy.  

  Oh, you mean I gotta learn 9X now? Didn't they get perverts like me to do
this sort of stuff back when they invented Ada? I read one book ("Studies in
Ada Style": Hibbard, Hisgen, Rosenberg, Shaw, Sherman) which allegedly studies
the possibilities of the Ada design, before compilers had actually been
implemented. The examples are like something from a second year data
structures course, there is nothing tricky in there at all.

>If you get too fancy, you end up writing the body of the task
>type as a finite state machine, with eight or nine accept statements
>or altenatives for each entry.  (I know, I've done it, and multi-page
>task bodies are a bitch to test.)

  Blagh. I have been writing Gofer (a functional language) for 2 years now for
my everyday needs and for this class, and I have been writing Ada for say 3
months purely for this class. I can find ~2500 lines of Gofer and ~1400 lines
of Ada. Considering how much I have achieved in Gofer and how little I have
achieved in Ada, I have to have serious doubts about the contribution of Ada
to software engineering! I have not previously been an evangelistic functional
programmer, but Ada is changing my mind :-).


John

Re: Newbie question about generic linked list tasks

[Robert I. Eachus]

In article <farrell.780558777@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:

 >   Blagh. I have been writing Gofer (a functional language) for 2
 > years now for my everyday needs and for this class, and I have been
 > writing Ada for say 3 months purely for this class. I can find
 > ~2500 lines of Gofer and ~1400 lines of Ada. Considering how much I
 > have achieved in Gofer and how little I have achieved in Ada, I
 > have to have serious doubts about the contribution of Ada to
 > software engineering! I have not previously been an evangelistic
 > functional programmer, but Ada is changing my mind :-).

    The goals of Ada 83 were to reduce maintenance costs as much as
possible without increasing the cost to create large applications.
The result is that small applications are often larger in Ada 83.
(We used to joke that the minimum size of an example was three pages.)
I've gotten much better at using the language, and I can often create
fairly sophisticated applications with only a few hundred lines of new
code, but one liners are still pretty rare.  (Although I came close
with that Fibonacci example.)

    Ada 9X will be a lot better in part because a lot more of the
library packages needed will be in the standard, and even better when
we get some public domain class libraries out.

    Ada will always have a long learning curve to become productive,
as will any large toolset.  It is always possible to build all your
own tools, and you should build some to understand how it is done.
But the best approach will always be to learn and use the available
toolsets.  As those grow, the time to learn them also grows.  Ada does
make it possible to learn to use toolsets more quickly, but the time
required is never zero.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Newbie question about generic linked list tasks

[John Farrell]

In <EACHUS.94Sep26095558@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>    Ada will always have a long learning curve to become productive,
>as will any large toolset.  It is always possible to build all your
>own tools, and you should build some to understand how it is done.
>But the best approach will always be to learn and use the available
>toolsets.  As those grow, the time to learn them also grows.  Ada does
>make it possible to learn to use toolsets more quickly, but the time
>required is never zero.

  Speaking of which, are there any toolsets available on the net? I found a
few libraries on the AJPO site, but not as much as I expected to.


John

Re: Newbie question about generic linked list tasks

[David Weller]

In article <farrell.780644250@coral.cs.jcu.edu.au>,
John Farrell <farrell@coral.cs.jcu.edu.au> wrote:
>
>  Speaking of which, are there any toolsets available on the net? I found a
>few libraries on the AJPO site, but not as much as I expected to.
>

You need to check the Public Ada Library -- that's at
wuarchive.wustl.edu (there's a few mirrors, but the only one I
remember is ftp.cdrom.com).  

If you're hoping to find Ada 9X libraries, you're outta luck though
-- it's a _wee bit_ too early for that.  Check back in November :-)


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Newbie question about generic linked list tasks

[John Farrell]

In <35q08a$1e5u@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:
>If I understand your problem, it has nothing to do with generics.  You
>want to write something like
>   task type List_Type is
>      entry Append (Other_List: in List_Type);
>         -- this := this & Other_List
>      ...
>   end List_Type;
>but you can't name List_Type in the parameter specification for entry
>Append because List_Type doesn't become visible until the end of the
>task-type declaration.

  You got it.

>Here is one workaround: 
>      subtype List_Type_Alias is List_Type;
>      task type List_Type is
>         entry Append (Other_List: in List_Type_Alias);
>         ...
>      end List_Type;

  Gosh, what a rort! A task type by any other name...

>The List_Type_Alias nonsense is a workaround required by RM 9.1(4), which
>states that the name of a task unit cannot be used within that unit
>itself as a type mark.  Three compilers crashed with internal
>errors while compiling a variant of this program (with the task body
>replaced by a body stub, other ellipses removed, and the generic part
>removed), so this may be a legal but unusuable solution.

  Thanks. This is beginning to sound like Constitutional Law.

>Here is another workaround: 

  ...


  I have to ask - if these things have workarounds, why is the restriction
there? Maybe this is more of a newbie question than the original :-).


John

Re: Newbie question about generic linked list tasks

[Robert I. Eachus]

In article <farrell.780560711@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:

  > Thanks. This is beginning to sound like Constitutional Law.

-- Yup!

  >   I have to ask - if these things have workarounds, why is the restriction
  > there? Maybe this is more of a newbie question than the original :-).

-- Because it isn't a restriction, it is a naming conflict.

-- You need to be able to name the current task object in the body of
-- the task, and you sometimes need to be able to refer to the task
-- type as well.  The design team decided to use the task type name
-- for the first for consistency with task objects.  This means a
-- different name must be used for the type.  Therefore if you need to
-- name the type (and since qualified names won't work) you have to
-- declare a subtype outside the task body.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...