Problem With Self-Referential Access-to-Subprogram Type

Problem With Self-Referential Access-to-Subprogram Type

[Tad Ashlock]

(Background information: I'm an Ada newbie using GNAT 3.15p on Windows
2000.)

In the demonstration code below, State1 compiles and works fine, but the
declaration of State2 generates an error (premature use of "State2").

package Test is
   --  A little ADT:
   type Test_Type is tagged private;
   function Get_Dummy (Tester : Test_Type) return Integer;
   procedure Set_Dummy (Tester : in out Test_Type; Dummy : in Integer);

   --  An access-to-function type that works (but Tester is read-only):
   type State1;
   type State1 is access function (Tester : Test_Type'Class)
                                  return State1;
   --  An access-to-procedure type that doesn't work:
   type State2;
   type State2 is access procedure (Tester : in out Test_Type'Class;
                                    Resultant_State : out State2);
   --                premature use of "State2" right here ^
private
   type Test_Type is
     tagged record
        Dummy : Integer;
     end record;
end Test;

I started off by calling functions via variables of type State1.  But
then I needed to make changes to the Tester parameter within the
functions (e.g. calling Set_Dummy).  So I decided to change to calling
procedures via variables of type State2.  But this resulted in error
messages (premature use of "State2").

Technically, I could still use an access-to-function type (State1) and
just change the Tester parameter to be an access to Test_Type'Class *and*
make all variables and constants of Test_Type aliased *and* pass them
using the 'Access attribute *and* change certian packages to be generic
*and* carefully instantiate them in the right scope to avoid the
"non-local pointer cannot point to local object" errors.

But that doesn't feel right.  The subprograms being accessed *do* have
side-effects and *should* be procedures rather than functions.  Changing
to the parameter to an access type to get around the "functions have
input parameters only" rule seems like cheating.  Besides, the changes
listed above seem like alot of hassle for very little return.
Effectively, I just want to change to returning the value via an "out"
parameter rather than via a function result.

Am I missing something obvious?

Thanks for your help,
Tad

RE: Problem With Self-Referential Access-to-Subprogram Type

[amado.alves]

You know the joke about how every problem can be solved by adding just another level of indirection?

   type State2;
   TYPE STATE2_PTR IS ACCESS STATE2;
   type State2 is access procedure (Tester : in out Test_Type'Class;
                                    Resultant_State : out STATE2_PTR);

Re: Problem With Self-Referential Access-to-Subprogram Type

[Dmitry A. Kazakov]

On 3 Nov 2003 08:58:45 -0800, taashlo@cyberdude.com (Tad Ashlock)
wrote:

>(Background information: I'm an Ada newbie using GNAT 3.15p on Windows
>2000.)
>
>In the demonstration code below, State1 compiles and works fine, but the
>declaration of State2 generates an error (premature use of "State2").
>
>package Test is
>   --  A little ADT:
>   type Test_Type is tagged private;
>   function Get_Dummy (Tester : Test_Type) return Integer;
>   procedure Set_Dummy (Tester : in out Test_Type; Dummy : in Integer);
>
>   --  An access-to-function type that works (but Tester is read-only):
>   type State1;
>   type State1 is access function (Tester : Test_Type'Class)
>                                  return State1;
>   --  An access-to-procedure type that doesn't work:
>   type State2;
>   type State2 is access procedure (Tester : in out Test_Type'Class;
>                                    Resultant_State : out State2);
>   --                premature use of "State2" right here ^

   type State2 is access procedure (Tester : in out Test_Type'Class;
                                    Resultant_State : access State2);

>private
>   type Test_Type is
>     tagged record
>        Dummy : Integer;
>     end record;
>end Test;
>
>I started off by calling functions via variables of type State1.  But
>then I needed to make changes to the Tester parameter within the
>functions (e.g. calling Set_Dummy).  So I decided to change to calling
>procedures via variables of type State2.  But this resulted in error
>messages (premature use of "State2").
>
>Technically, I could still use an access-to-function type (State1) and
>just change the Tester parameter to be an access to Test_Type'Class *and*
>make all variables and constants of Test_Type aliased *and* pass them
>using the 'Access attribute *and* change certian packages to be generic
>*and* carefully instantiate them in the right scope to avoid the
>"non-local pointer cannot point to local object" errors.
>
>But that doesn't feel right.  The subprograms being accessed *do* have
>side-effects and *should* be procedures rather than functions.  Changing
>to the parameter to an access type to get around the "functions have
>input parameters only" rule seems like cheating.  Besides, the changes
>listed above seem like alot of hassle for very little return.
>Effectively, I just want to change to returning the value via an "out"
>parameter rather than via a function result.
>
>Am I missing something obvious?

You are using tagged types, why then you don't use dispatching calls?
Access to subprogram is a sort of polymorphism of poor man. Perhaps
you can review your design with that respect. Namely, to put the
knowledge of what should be done into Test_Type'Class. Probably it
would imply multiple dispatch/inheritance, then for both there are
workarounds in Ada.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Problem With Self-Referential Access-to-Subprogram Type

[Tad Ashlock]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<80teqv099lspc5d4osf2gmu7cld46i0lvb@4ax.com>...
> On 3 Nov 2003 08:58:45 -0800, taashlo@cyberdude.com (Tad Ashlock)
> wrote:

[snip]

> >   --  An access-to-procedure type that doesn't work:
> >   type State2;
> >   type State2 is access procedure (Tester : in out Test_Type'Class;
> >                                    Resultant_State : out State2);
> >   --                premature use of "State2" right here ^
> 
>    type State2 is access procedure (Tester : in out Test_Type'Class;
>                                     Resultant_State : access State2);

Sure, but why should I have to?  What is the difference between a
function return value and an "out" parameter that makes what I'm
trying to do an error for one but not the other?

[snip]

> >Am I missing something obvious?
> 
> You are using tagged types, why then you don't use dispatching calls?

The example code in the original post didn't show it, but I *am* using
dispatching calls, but along a different axis.  But your idea is still
an interesting one.  Since Ada separates the concepts of packaging and
type extension, there are some possibilities that I'll have to ponder.

But my question above still stands.  It appears that there is
something special about a function return value that can't be replaced
with a procedure "out" parameter.

> Access to subprogram is a sort of polymorphism of poor man. Perhaps
> you can review your design with that respect. Namely, to put the
> knowledge of what should be done into Test_Type'Class. Probably it
> would imply multiple dispatch/inheritance, then for both there are
> workarounds in Ada.
> 
> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de

Dmitry, thank you,
Tad

Re: Problem With Self-Referential Access-to-Subprogram Type

[Tad Ashlock]

"amado.alves" <amado.alves@netcabo.pt> wrote in message news:<mailman.266.1067880764.25614.comp.lang.ada@ada-france.org>...
> You know the joke about how every problem can be solved by adding just 
> another level of indirection?
> 
>    type State2;
>    TYPE STATE2 PTR IS ACCESS STATE2;
>    type State2 is access procedure (Tester : in out Test Type'Class;
>                                     Resultant State : out STATE2 PTR);

Thanks for your response, Amado.  Dmitry Kazakov pointed out the same
solution in a different message.  (Although from your post timestamps,
it appears that you suggested it first. :)  But I question the
difference between a function return value and a procedure "out"
parameter that makes what I'm trying to do an error for one, but not
the other.

Thanks again,
Tad

Re: Problem With Self-Referential Access-to-Subprogram Type

[Dmitry A. Kazakov]

On 4 Nov 2003 05:52:01 -0800, taashlo@cyberdude.com (Tad Ashlock)
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<80teqv099lspc5d4osf2gmu7cld46i0lvb@4ax.com>...
>> On 3 Nov 2003 08:58:45 -0800, taashlo@cyberdude.com (Tad Ashlock)
>> wrote:
>
>[snip]
>
>> >   --  An access-to-procedure type that doesn't work:
>> >   type State2;
>> >   type State2 is access procedure (Tester : in out Test_Type'Class;
>> >                                    Resultant_State : out State2);
>> >   --                premature use of "State2" right here ^
>> 
>>    type State2 is access procedure (Tester : in out Test_Type'Class;
>>                                     Resultant_State : access State2);
>
>Sure, but why should I have to?  What is the difference between a
>function return value and an "out" parameter that makes what I'm
>trying to do an error for one but not the other?

[...]

>But my question above still stands.  It appears that there is
>something special about a function return value that can't be replaced
>with a procedure "out" parameter.

Yes, there is a difference. Technically, for an out parameter the
compiler should still know the object constraints. Consider a case
when the object be passed by value on the stack. State2 is being
declared, so the compiler has no clue. Differently to an out
parameter, a return value is unconstrained. For example you can:

declare
   X : String := Get_Whatever_Length_I_Need;

This does not work with out parameters. Because the compiler should
anyway treat return values in a special way it is no matter whether
its type is fully known. So the difference in general between outs and
returns is.

Though in your case there might actually be no difference (for types
like access-to-subprogram). So theoretically one could drop this
restriction for scalar, access types and some other types, but this
would make the language too complex and its rules more difficult to
understand.

If Ada allowed 'Class for all types, as it IMO should, then you could
write:

    type State2 is access procedure (Tester : in out Test_Type'Class;
                         Resultant_State : in out State2'Class);

with the desired effect. Unfortunately it does not allow this.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Problem With Self-Referential Access-to-Subprogram Type

[Marius Amado Alves]

On Tue, 2003-11-04 at 14:24, Dmitry A.Kazakov wrote:
> Yes, there is a difference. Technically, for an out parameter the
> compiler should still know the object constraints.

Only at runtime. Consider Ada.Text_IO.Get (Item : out String). What
constraints is the compiler knowing here?

Re: Problem With Self-Referential Access-to-Subprogram Type

[Dmitry A. Kazakov]

On Tue, 04 Nov 2003 14:52:33 +0000, Marius Amado Alves
<amado.alves@netcabo.pt> wrote:

>On Tue, 2003-11-04 at 14:24, Dmitry A.Kazakov wrote:
>> Yes, there is a difference. Technically, for an out parameter the
>> compiler should still know the object constraints.
>
>Only at runtime. Consider Ada.Text_IO.Get (Item : out String). What
>constraints is the compiler knowing here?

It knows that there are bounds which cannot be changed. If Item were
of String (1..5) the compiler would probably choose another way of
parameter passing than for String (<>) with the consequence that the
stack frame would be different. I suppose, that one could allow
premature use of types. Even as evil as:

type X;
type Y is record
   What_Is_That : X;
end Y;

but the price would be too high. We will have 10,000 pages of ARM to
describe it and a pair or two halting problems to solve. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Problem With Self-Referential Access-to-Subprogram Type

[Marius Amado Alves]

On Wed, 2003-11-05 at 08:31, Dmitry A.Kazakov wrote:
> >> Yes, there is a difference. Technically, for an out parameter the
> >> compiler should still know the object constraints.

> >Only at runtime. Consider Ada.Text_IO.Get (Item : out String). What
> >constraints is the compiler knowing here?

> It knows that there are bounds which cannot be changed. If Item were
> of String (1..5) the compiler would probably choose another way of
> parameter passing than for String (<>) with the consequence that the
> stack frame would be different.

Irrelevant. This applies to return types just as well.

The original poster has a very good question--which has found no real
answer yet. My guess is it comes down to the hardware-orientedness of
Ada. I was surprised the *first* form compiled.

Re: Problem With Self-Referential Access-to-Subprogram Type

[Dmitry A. Kazakov]

On Wed, 05 Nov 2003 11:27:22 +0000, Marius Amado Alves
<amado.alves@netcabo.pt> wrote:

>On Wed, 2003-11-05 at 08:31, Dmitry A.Kazakov wrote:
>> >> Yes, there is a difference. Technically, for an out parameter the
>> >> compiler should still know the object constraints.
>
>> >Only at runtime. Consider Ada.Text_IO.Get (Item : out String). What
>> >constraints is the compiler knowing here?
>
>> It knows that there are bounds which cannot be changed. If Item were
>> of String (1..5) the compiler would probably choose another way of
>> parameter passing than for String (<>) with the consequence that the
>> stack frame would be different.
>
>Irrelevant. This applies to return types just as well.

They are "bad" anyway. A return value is potentially a newly allocated
object. An out parameter is not (copy out does not count). So a
difference does exist.

BTW, there is an AI for returning / initializing limited type objects.
Let's see (:-))

>The original poster has a very good question--which has found no real
>answer yet. My guess is it comes down to the hardware-orientedness of
>Ada.

C++ is also hardware-oriented, but solves this other way, which I do
not like much.

Returning to Ada let's compare:

   type Mysterious;

   function Create return Mysterious;
   Init : constant Mysterious; -- Illegal

   procedure Baz (X : Mysterious := Init); -- Illegal
   procedure Bar (X : Mysterious := 0);  -- Illegal, Ada is not C++!
   procedure Foo (X : Mysterious := Create); -- Illegal
   ...
   type Mysterious is new Integer;
   Init : constant Mysterious := 0;

with

   type Mysterious is private;

   function Create return Mysterious;
   Init : constant Mysterious;

   procedure Bar (X : Mysterious := Create);
   procedure Bar (X : Mysterious := 0);  -- Still illegal
   procedure Foo (X : Mysterious := Init);
   ...
private
   type Mysterious is new Integer;
   Init : constant Mysterious := 0;

Private types are much more prematurely usable! (:-))

BTW there is a more serious problem than premature use. That is an
inability to hide the parameter defaults of a subroutine if the type
has to be private. You have to expose Init and Create, even if their
direct use is undesirable.

> I was surprised the *first* form compiled.

Well, now the language lawyers have to say ... (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Problem With Self-Referential Access-to-Subprogram Type

[Marius Amado Alves]

On Wed, 2003-11-05 at 13:33, Dmitry A.Kazakov wrote:
> ... Private types are much more prematurely usable! (:-))

Indeed. And they make *both* definitions possible. (I'm ashamed I did
not remembered this before, instead of access types.)

But the original question (for incomplete types) remains unanswered.

Re: Problem With Self-Referential Access-to-Subprogram Type

[Adam Beneschan]

Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.278.1068031675.25614.comp.lang.ada@ada-france.org>...
> On Wed, 2003-11-05 at 08:31, Dmitry A.Kazakov wrote:
> > >> Yes, there is a difference. Technically, for an out parameter the
> > >> compiler should still know the object constraints.
>  
> > >Only at runtime. Consider Ada.Text_IO.Get (Item : out String). What
> > >constraints is the compiler knowing here?
>  
> > It knows that there are bounds which cannot be changed. If Item were
> > of String (1..5) the compiler would probably choose another way of
> > parameter passing than for String (<>) with the consequence that the
> > stack frame would be different.
> 
> Irrelevant. This applies to return types just as well.
> 
> The original poster has a very good question--which has found no real
> answer yet. My guess is it comes down to the hardware-orientedness of
> Ada. I was surprised the *first* form compiled.

It should not have compiled.  8.3(19) says that a declaration is
hidden from all visibility until the end of the declaration, with some
exceptions that don't apply here.  So the type "State1" should not
have been visible until *after* the semicolon following "return
State1", and thus the compiler should have reported an error upon
seeing "return State1".

There is an Ada Issue (AI95-00313) suggesting that the rules be
modified so that an access-to-subprogram type declaration can refer to
itself anywhere after the word "access"; this would make the
declarations of both State1 and State2 legal (and the incomplete type
declarations wouldn't be necessary).  The feeling at the time was that
the additional work needed to change the language and the compilers
shouldn't be required if no one has run into the problem in practice. 
I've let them know that someone now has run into it.

                                  -- Adam

Re: Problem With Self-Referential Access-to-Subprogram Type

[Marius Amado Alves]

On Wed, 2003-11-05 at 17:49, Adam Beneschan wrote:
> ... The feeling at the time was that
> the additional work needed to change the language and the compilers
> shouldn't be required if no one has run into the problem in practice. 
> I've let them know that someone now has run into it.

Did you verify that the problem was "real"? The example does not seem to
show enough. Can be just an experimentation of the general construction,
with no specific application in mind. Some newbies do that. (In which
case the 2002 decision should probably stand. Private types solve the
general problem.)

Re: Problem With Self-Referential Access-to-Subprogram Type

[Tad Ashlock]

Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.285.1068058551.25614.comp.lang.ada@ada-france.org>...
> On Wed, 2003-11-05 at 17:49, Adam Beneschan wrote:
> > ... The feeling at the time was that
> > the additional work needed to change the language and the compilers
> > shouldn't be required if no one has run into the problem in practice. 
> > I've let them know that someone now has run into it.
> 
> Did you verify that the problem was "real"? The example does not seem to
> show enough. Can be just an experimentation of the general construction,
> with no specific application in mind. Some newbies do that. (In which
> case the 2002 decision should probably stand. Private types solve the
> general problem.)

Well, as the OP I can't really say how "real" the problem is.  But I
can describe what it is I'm trying to accomplish.

What I'm trying to do is implement (in Ada) the ideas in the book
"Practical Statecharts in C/C++" by Miro Samek, CMP Books, 2002, ISBN
1-57820-110-1 <http://www.quantum-leaps.com/writings/book.htm>.  The
(quite ingenious) idea is that the current state of a hierarchical
state machine can be represented by nothing more than a reference (a
function pointer in C++) to the state handling function.  And to
implement the hierarchical aspect of statecharts, each state handling
function returns a reference to its parent state if it doesn't handle
the passed-in event itself.

Of course there are other ways of getting the required information
back from the state handler, but I am trying to keep the Ada
implementation similar to the original C++ implementation.  At least
where it makes sense to do so.  That's what started me exploring the
possibility of an access-to-function type being defined as returning a
value of its own type.  I then stumbled across the inability to
convert my state handler functions to procedures.  And that prompted
my original posting.  I now see that my original access-to-function
type was erroneous and therefore so is my entire line of reasoning. 
Oops!

Whether or not this situation justifies changing Ada is well beyond
me.  I certainly wouldn't like to see this capability added just
because C++ can do it (besides, it's a hack in C++ anyway).  But if
the Ada-Powers-That-Be decide that this capatility is worth adding to
Ada, I could certainly make use of it.

Thanks again,
Tad

Re: Problem With Self-Referential Access-to-Subprogram Type

[Warren W. Gay VE3WWG]

Tad Ashlock wrote:

> Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.285.1068058551.25614.comp.lang.ada@ada-france.org>...
> 
>>On Wed, 2003-11-05 at 17:49, Adam Beneschan wrote:
>>
>>>... The feeling at the time was that
>>>the additional work needed to change the language and the compilers
>>>shouldn't be required if no one has run into the problem in practice. 
>>>I've let them know that someone now has run into it.
>>
>>Did you verify that the problem was "real"? The example does not seem to
>>show enough. Can be just an experimentation of the general construction,
>>with no specific application in mind. Some newbies do that. (In which
>>case the 2002 decision should probably stand. Private types solve the
>>general problem.)
> 
> Well, as the OP I can't really say how "real" the problem is.  But I
> can describe what it is I'm trying to accomplish.
> 
> What I'm trying to do is implement (in Ada) the ideas in the book
> "Practical Statecharts in C/C++" by Miro Samek, CMP Books, 2002, ISBN
> 1-57820-110-1 <http://www.quantum-leaps.com/writings/book.htm>.  The
> (quite ingenious) idea is that the current state of a hierarchical
> state machine can be represented by nothing more than a reference (a
> function pointer in C++) to the state handling function.  And to
> implement the hierarchical aspect of statecharts, each state handling
> function returns a reference to its parent state if it doesn't handle
> the passed-in event itself.
> 
> Of course there are other ways of getting the required information
> back from the state handler, but I am trying to keep the Ada
> implementation similar to the original C++ implementation.  At least

I know this doesn't map to the "C++ way", but would not an
array of function pointers with an enumerated type to choose
the function not work?  Rather than working with "pointers",
directly, you choose the pointer using the enumerated type
as an array subscript. This also avoids violating the
"never compare pointers" rule (not all platforms guarantee
that the representation of 2 equivalent addresses will be
identical). This may come up when you need to compare if
one state is equal to another. Comparing pointers may work
on most modern platforms, it is not guaranteed to work
(I think segmented architectures is where you have the
greatest difficulty with this).
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg