Re: Callback in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 29 Nov 2010 02:12:33 -0800 (PST), Maciej Sobczak wrote:

> On Nov 29, 9:41�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> And now an equivalent example with functions, please. :-)
>>
>> �� �procedure Foo (Closure : function return Integer);
>> �� �function Bar return Integer;
>> �� �...
>> �� �Foo (Bar);
>>
>> There is no difference.
> 
> There is.
> 
>> * Ada is not bottom up as C++, it can resolve using the type of the result.
> 
> But here there is no type of the result.

Of course there is. The result type is an anonymous procedural type:

   type <anonymous> is function return Integer;

> Bar is not even called, so
> there is no result on which you could disambiguate this construct.

Yes, it is an object. BTW, the following is legal Ada:

   package P is
      type X is (V);
   end P;
   package Q is
      function V return Float;
   end Q;
   package body Q is
      function V return Float is
      begin
         return 3.14;
      end V;
   end Q;
   use P, Q;
   X : Float := V; -- Resolved between P.V and Q.V

> In order to make your reasoning complete you would have to introduce
> additional way of using function names:
> 
> 1. This way:
> 
>    Bar
> 
> would mean that the function is called. The type of result can be used
> to disambiguate the overloaded calls. For the brave: watch out
> enumerations.
> 
> 2. This way:
> 
>    Bar
> 
> would mean that the function is *not* called, but is denoted as a
> first-class entity.

Yes and both ways already exist in Ada, how otherwise would you be able to
take an access to the subprogram:

   Bar'Access

reads #2: use the object Bar and apply 'Access to it. It does not read #1:
call Bar and apply 'Access to the result.

Once you introduce subprograms as first-class entities in any form (even
through pointers), you get the ambiguity. The same happens with referential
types, e.g. Ptr as self vs. Ptr as target. There is nothing to do about it.
Whatever magic words you would put around Ptr it would never be clear if
these apply to Ptr or to Ptr.all, without further premises.

The right answer is resolution according to the type. In a typed system the
context tells the meaning of the operation. No problem.

P.S. In fact Ada had this kind of stuff from the day one. In Ada 83 there
were no pointers to subprograms, but it had tasks. We customary used tasks
where a program needed as a parameter. Nobody died.

P.P.S. As Ada strives to introduce procedural-literals, e.g. conditional
expressions, fancy quantified expressions and other awful stuff, it will
inevitably require subprogram types, because you cannot get pointer of a
literal. What is all this mess worth of if it cannot be given as a
parameter?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de