* Re: Newbie question about generic linked list tasks [not found] ` <35qb51$ksu@rational.rational.com> @ 1994-09-22 17:55 ` Bob Kitzberger 0 siblings, 0 replies; 8+ messages in thread From: Bob Kitzberger @ 1994-09-22 17:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <EACHUS.94Sep21134917@spectre.mitre.org>]
[parent not found: <farrell.780237190@coral.cs.jcu.edu.au>]
* Re: Newbie question about generic linked list tasks [not found] ` <farrell.780237190@coral.cs.jcu.edu.au> @ 1994-09-23 10:53 ` Robert I. Eachus 1994-09-26 5:52 ` John Farrell 0 siblings, 1 reply; 8+ messages in thread From: Robert I. Eachus @ 1994-09-23 10:53 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Newbie question about generic linked list tasks 1994-09-23 10:53 ` Robert I. Eachus @ 1994-09-26 5:52 ` John Farrell 1994-09-26 9:55 ` Robert I. Eachus 0 siblings, 1 reply; 8+ messages in thread From: John Farrell @ 1994-09-26 5:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Newbie question about generic linked list tasks 1994-09-26 5:52 ` John Farrell @ 1994-09-26 9:55 ` Robert I. Eachus 1994-09-27 5:37 ` John Farrell 0 siblings, 1 reply; 8+ messages in thread From: Robert I. Eachus @ 1994-09-26 9:55 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Newbie question about generic linked list tasks 1994-09-26 9:55 ` Robert I. Eachus @ 1994-09-27 5:37 ` John Farrell 1994-09-28 22:15 ` David Weller 0 siblings, 1 reply; 8+ messages in thread From: John Farrell @ 1994-09-27 5:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Newbie question about generic linked list tasks 1994-09-27 5:37 ` John Farrell @ 1994-09-28 22:15 ` David Weller 0 siblings, 0 replies; 8+ messages in thread From: David Weller @ 1994-09-28 22:15 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <35q08a$1e5u@watnews1.watson.ibm.com>]
* Re: Newbie question about generic linked list tasks [not found] ` <35q08a$1e5u@watnews1.watson.ibm.com> @ 1994-09-26 6:25 ` John Farrell 1994-09-26 9:44 ` Robert I. Eachus 0 siblings, 1 reply; 8+ messages in thread From: John Farrell @ 1994-09-26 6:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Newbie question about generic linked list tasks 1994-09-26 6:25 ` John Farrell @ 1994-09-26 9:44 ` Robert I. Eachus 0 siblings, 0 replies; 8+ messages in thread From: Robert I. Eachus @ 1994-09-26 9:44 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1994-09-28 22:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <farrell.780154278@coral.cs.jcu.edu.au> [not found] ` <35qb51$ksu@rational.rational.com> 1994-09-22 17:55 ` Newbie question about generic linked list tasks Bob Kitzberger [not found] ` <EACHUS.94Sep21134917@spectre.mitre.org> [not found] ` <farrell.780237190@coral.cs.jcu.edu.au> 1994-09-23 10:53 ` Robert I. Eachus 1994-09-26 5:52 ` John Farrell 1994-09-26 9:55 ` Robert I. Eachus 1994-09-27 5:37 ` John Farrell 1994-09-28 22:15 ` David Weller [not found] ` <35q08a$1e5u@watnews1.watson.ibm.com> 1994-09-26 6:25 ` John Farrell 1994-09-26 9:44 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox