Problems with visibility of implicit function...

Problems with visibility of implicit function...

[Dale Stanbrough]

I've got some problems calling an implicity declared function
which is hidden by an explicity declared one. I've tried
renaming, only to end up with infinite recursion. Is the
implicity declared function "hidden from all visibility"?

--------------------------------------------
package lists is
	type list is private;
	
	function full(item:list) return boolean;
private
	...
end lists;

with lists;
package stacks is
	type stack is private;
	
	function full(item:stack) return boolean;
	
private
	type stack is new lists.list;
	-- inherited & implicitly defined full...
	-- function full(item:stack) return boolean;
end;

package body stacks is

	function full(item:stack) return boolean is
	begin
		...what?
		should i just call on lists.full?
	end;
	
end stacks;


BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
do with squirrels?  ?:-)

Dale

Re: Problems with visibility of implicit function...

[Tucker Taft]

Dale Stanbrough (dale@goanna.cs.rmit.EDU.AU) wrote:

: I've got some problems calling an implicity declared function
: which is hidden by an explicity declared one. I've tried
: renaming, only to end up with infinite recursion. Is the
: implicity declared function "hidden from all visibility"?

Yes, but you can reach an equivalent one by appropriate
use of (view) conversion.

: --------------------------------------------
: package lists is
: 	type list is private;
: 	
: 	function full(item:list) return boolean;
: private
: 	...
: end lists;

: with lists;
: package stacks is
: 	type stack is private;
: 	
: 	function full(item:stack) return boolean;
: 	
: private
: 	type stack is new lists.list;
: 	-- inherited & implicitly defined full...
: 	-- function full(item:stack) return boolean;
: end;

: package body stacks is

: 	function full(item:stack) return boolean is
: 	begin
: 		...what?
: 		should i just call on lists.full?

                return Lists.full(Lists.list(item));

should work.


: 	end;
: 	
: end stacks;


: BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
: do with squirrels?  ?:-)

Ask Bob Duff.

: Dale

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Problems with visibility of implicit function...

[progers]

>Dale Stanbrough (dale@goanna.cs.rmit.EDU.AU) wrote:
>
[snip]
>
> BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
> do with squirrels?  ?:-)

For that matter, you've missed the ecology index entries...  Go look up "unpolluted" :)

pat
---------------
Patrick Rogers
progers@acm.org

Re: Problems with visibility of implicit function...

[Robert A Duff]

In article <4q6tgq$n25@uuneo.neosoft.com>,  <progers@acm.org> wrote:
>>Dale Stanbrough (dale@goanna.cs.rmit.EDU.AU) wrote:
>>
>[snip]
>>
>> BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
>> do with squirrels?  ?:-)

They're both animals.

This is all just a bit of silliness on my part.  One gets tired of
writing all that serious and arcane stuff that goes into an
International Standard.  And producing a good index is long and tedious
work.  The user of an index just looks things up, but the author has to
*read* it, from start to finish, numerous times.

During the design of Ada 9X, one of the reviewers (I think it was Dave
Emery) sent in a comment saying that if alligators are included in the
index, then in fairness to squirrels, they should be included, too
(since the AARM does, in fact, use the word "squirrel").  So I obeyed
this suggestion.

>For that matter, you've missed the ecology index entries...  Go look up
>"unpolluted" :)

Right.  That one should be self-explanatory, and is equally silly.  It
was also triggered by a comment from a reviewer (I think it was Norman
Cohen, master of puns).

In case anybody wants to know what on earth I'm babbling about, just
look up the following terms in the Index of the RM:

    constructor
    heap management
    unpolluted

and in the index of the AARM:

    squirrel away

- Bob

Re: Problems with visibility of implicit function...

[Chris Warack <sys mgr>]

In article <4q67nn$sp5@goanna.cs.rmit.EDU.AU>, Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:
|> I've got some problems calling an implicity declared function
|> which is hidden by an explicity declared one. I've tried
|> renaming, only to end up with infinite recursion. Is the
|> implicity declared function "hidden from all visibility"?

Yes

|> --------------------------------------------
|> package lists is
|> 	type list is private;
|> 	
|> 	function full(item:list) return boolean;
|> private
|> 	...
|> end lists;
|> 
|> with lists;
|> package stacks is
|> 	type stack is private;
|> 	
|> 	function full(item:stack) return boolean;
|> 	
|> private
|> 	type stack is new lists.list;
|> 	-- inherited & implicitly defined full...
|> 	-- function full(item:stack) return boolean;
|> end;
|> 
|> package body stacks is
|> 
|> 	function full(item:stack) return boolean is
|> 	begin
|> 		...what?
|> 		should i just call on lists.full?
|> 	end;

There are at least three ways to go with this:
  1) Use a different name for Stacks.full
      -- you can then complete the visible definition by a renaming
         declaration in the body
  2) Use a tagged type for lists and extend it for stacks (probably not
     good design in this situation).
  3) call lists.full -- return Lists.Full(Lists.List(item)); to replace
     "what?" above.
     
    Does any compiler optimize case three into calling Lists.Full directly
    in case 3?  (e.g., giving Stacks.full the same linker symbol...?)

|> end stacks;
|> 
|> 
|> BTW WRT Annotated LRM, 8.5.4(8.g), what do alligators have to
|> do with squirrels?  ?:-)
|> 
|> Dale

-- 
Christopher A. Warack, Capt, USAF  cwarack@cs.usafa.af.mil (719) 472-2401
Computer Science Department, US Air Force Academy
This content in no way reflects the opinions, standards, or policy
of the USAF Academy, or the US government.

Re: Problems with visibility of implicit function...

[Norman H. Cohen]

In article <4q67nn$sp5@goanna.cs.rmit.EDU.AU>, Dale Stanbrough
<dale@goanna.cs.rmit.EDU.AU> writes: 

|> I've got some problems calling an implicity declared function
|> which is hidden by an explicity declared one. I've tried
|> renaming, only to end up with infinite recursion. Is the
|> implicity declared function "hidden from all visibility"?
|>
|> --------------------------------------------
|> package lists is
|>      type list is private;
|>
|>      function full(item:list) return boolean;
|> private
|>      ...
|> end lists;
|>
|> with lists;
|> package stacks is
|>      type stack is private;
|>
|>      function full(item:stack) return boolean;
|>
|> private
|>      type stack is new lists.list;
|>      -- inherited & implicitly defined full...
|>      -- function full(item:stack) return boolean;
|> end;
|>
|> package body stacks is
|>
|>      function full(item:stack) return boolean is
|>      begin
|>              ...what?
|>              should i just call on lists.full?
|>      end;
|>
|> end stacks;

Yes, this is an annoying phenomenon.  Because the explicit Stack version
of Full is declared in the visible part, the implicit (inherited) version
is "born hidden" at the point of the derived-type declaration in the
private part.  (This has nothing to do with vlisble versus private, but
just with the fact that the explicit declaration occurs first, so that
the implicit declaration is within the scope of the explicit one.)

The most straightforward solution is: 

   package body Stacks is
      function Full (Item: Stack) return Boolean is
      begin
         return Lists.Full ( List(Stack) );
      end Full;
   end Stacks;

Jonas Nygren asked a similar question not too long ago (message
<316E12F2.37BC@ehs.ericsson.se>), and I suggested the following solution,
which is more intricate but should have no run-time overhead: 

   with Lists;
   package Stacks is
      type Stack is private;
      function Full (Item: Stack) return Boolean;
   private
      package Inner is
         type Parent_Of_Stack is new Lists.List;
         function Parent_Of_Full (Item: Parent_Of_Stack) return Boolean
            renames Full;
      end Inner;
      type Stack is new Inner.Parent_Of_Stack;
      function Full (Item: Stack) return Boolean renames Parent_Of_Full;
         -- Renames
         --    function Parent_Of_Full(Item: Stack) return Boolean;
         -- inherited from  Inner.Parent_Of_Stack and implicitly
         -- declared just after the full declaration for Stack.
   end Stacks;

The trick is to impose an intermediate derived type in which the function
to be inherited is known by a different name, and is thus not hidden by
the declaration of Full in the visible part of Stacks.

--
Norman H. Cohen    ncohen@watson.ibm.com