milne@ICSE.UCI.EDU (Alastair Milne) (06/18/86)
*PRIVATE REPLY*
This message was intended to be a private reply to an info-ada message
from Rick Wessman, but several tries to reply to his address and
variations on it have met with failure. The info-ada distribution list
is the only means left to me. My apologies to those whom this message
does not concern.
Alastair Milne
------- Forwarded Message
To: Rick Wessman <nike!styx!lll-crg!seismo!rochester!ritcv!cci632!ccird1!rrw%cad@ucbvax.Berkeley.EDU>
Subject: Re: Generic list processing
In-Reply-To: Your message of 10 Jun 86 11:59:35 GMT.
<457@ccird1.UUCP>
Date: Wed, 11 Jun 86 18:58:15 -0800
From: Alastair Milne <milne@ICSE.UCI.EDU>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
generic
type LIST_TYPE is private;
type LIST_POINTER is access LIST_TYPE;
package LIST_OPS is
procedure DELETE (item: LIST_POINTER; head_of_list: in out LIST_POINTER);
end LIST_OPS;
package body LIST_OPS is
. . .
if item = head_of_list and
then head_of_list.all.next = head_of_list then
- - - -------------------------^A ###
- - - --### A:error: LRM 4.1.3: inappropriate prefix
. . .
item.all.previous.all.next := item.all.next;
- - - --------^A ###
- - - --------------------------------------^B ###
- - - --### A:error: LRM 4.1.3: inappropriate prefix
- - - --### B:error: LRM 4.1.3: inappropriate prefix
item.all.next.all.previous := item.all.previous;
- - - --------^A ###
- - - --------------------------------------^B ###
- - - --### A:error: LRM 4.1.3: inappropriate prefix
- - - --### B:error: LRM 4.1.3: inappropriate prefix
. . .
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I don't understand the error flagged at the ".all" use. This should be
alright. Are you sure that the error indication didn't actually occur at
the next ".<id>" beyond it, as in the other error reports? If not, this
one puzzles me.
But as for protesting the use of ".next" and ".previous": you don't
have any, and there is not even any necessity that the type accessed be a
record: the generic declaration simply indicates that some data
structure will be used as an element, and it will have an access type to
it. There is no requirement whatever that it be a record, or that it
have either "next" or "previous" field.
I think what you want is a list element structure which consists
of "next" and "previous" fields and an access to the generic element, as
in:
type ListElt;
type EltPtr is access ListElt;
type ListElt is record
Next, Previous: EltPtr; -- access to next and previous
-- list elements.
Element: LISTPOINTER; -- access to the generic object
-- contained in this list element.
end record;
If the package is simply to maintain a single doubly-linked display list,
this structure, and the object which accesses the head of the list, can be
declared, and the objects automatically initialised, in the package body,
and Delete, Insert, etc., etc., would simply take as parameters
generic objects.
If, however, you prefer that your client units be able to instantiate
lists whenever they want them, then I suggest:
<your current generic declarations>
package ListOps is
-- other declarations as needed.
type ListElt is private;
type EltPtr is access ListElt;
-- other declarations as needed.
procedure Delete(in item: <generic object>; in out ListHead: EltPtr);
-- note the change. ^^^^^^^^^^^^^^^^^^^
-- similar format for Insert, Exchange, Relink, or whatever else.
private
type ListElt is record
Next, Previous: EltPtr; -- access to next and previous
-- list elements.
Element: <generic access>; -- access to the generic object
-- contained in this list element.
end record;
end ListOps;
(I'm not bothering here with the possibilities of limited private, or
default expressions for the access fields (they're null by default
anyway), though, depending on how exactly you want to use the package,
they might be useful.)
By the way, you don't really need all those ".all"'s. If you follow an
access object reference with a component reference, the indirection is
done automatically. However, the ".all" certainly has some documentation
value. Personally I regret that Ada did away with such indirection
symbols as "^" from Pascal and Modula-2. It doesn't seem wise to me to
make the indirection operation implicit. Please pardon me if this is all
old hat.
Hope this helps,
Alastair Milne
------- End of Forwarded Message