Re: in defense of GC

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

On Sun, 04 Feb 2007 21:24:01 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 03 Feb 2007 15:28:53 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>>>>
>>>>> Closure don't "make things global". They do it as much as returning an
>>>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>>>> people, that makes a value global and we all know, global is bad --
>>>>> how nonsensical is that?).
>>>>
>>>> You return a value of the type (Integer) which scope encloses the
>>>> subprogram returning that value.
>>> 
>>> Same applies to closures when they are returned. Where is the problem?
>>
>> The problem is this:
>>
>> function Foo return ?What? is
>>    type Bar is ...;
>>    X : Bar;
>> begin
>>    return X;
>> end Foo;
>>
>>>> I am a long proponent of procedural types for Ada. Now consider. A
>>>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>>>> What else you need? [Note, this is still not an upward closure, I am
>>>> opposing.]
>>> 
>>> I do need that
>>> 
>>>   function Make_a_Stepper (K:Integer) return ... is
>>> 
>>>       N : Integer := Complicated_Function(K);
>>> 
>>>       function Stepper(F:Foo) return Foo is
>>>     
>>>         begin
>>>           
>>>           return Foo + N;
>>> 
>>>         end;
>>> 
>>>     begin
>>>       return Stepper;
>>>     end;
>>> 
>>> would work. And no nitpicking, please, if I made syntax error here: The
>>> intention should be clear.
>>
>> I suppose it is. Here I propose a closure-free solution:
>>
>> package Something_Very_Functional is
>>    type function Stepper (F : Foo) return Foo;
>>       -- The type of a function we want to pass somewhere
>>    procedure Step_It (Visitor : Stepper'Class);
>>    ...
>> end Something_Very_Functional;
>>
>> package Stepper_Factory is
>>    function Create (K : Integer) return Stepper'Class;
>>       -- This is a constructor for the stepper provided here. We
>>       -- don't want to expose any details about it, so the
>>       -- Stepper type is made private.
>> private
>>    type Stepper_With_A_Parameter (N : Integer) is new Stepper;
>>       -- This is a derived type to have a discriminant, which could serve
>>       -- as a carrier for the locally computed value.
>> end Stepper_Factory;
>>
>> package body Stepper_Factory is
>>    function Create (K : Integer) return Stepper'Class is
>>    begin
>>       return
>>          Stepper_With_A_Parameter'
>>          (  N => Complicated_Function (K),
>>          with
>>             begin
>>                return F + N;
>>             end;
>>          );
>> end Stepper_Factory;
>>
>> Some notes. Within the "procedural record extension" the visibility rules
>> are such that local variables of Create are invisible. The package data are
>> visible and accessibility checks are made to ensure that the scope of
>> Stepper_With_A_Parameter is not statically deeper than one of Stepper.
>>
>> -----------------
>> BTW, I prefer an OO design with Stepper being an abstract primitive
>> operation of some object:
>>
>> type Data is abstract ...;
>> function Stepper (State : in out Data; F : Foo) return Foo is abstract;
>> procedure Step_It (Data : in out Data'Class);
>> -------------------
> 
> Yes. That is exactly what I referred to in earlier posts as clumsy --
> to replace closure by this kind of dance.

Do you refer to the first variant or to the second?

Doesn't it solve the problem? Note that in your solution you were unable to
describe what function Make_a_Stepper actually returns. Consider also this:

protected type Bar is
   function Make_a_Mess return ...;
private
   Baz : Integer;
      -- To be put into the closure together with barriers of the entries!

how do you return a closure from a protected object or a task rendezvous?
Will it be able to assign Baz?

I certainly prefer OO solution because it explicitly maintains the context
of the operation. It is easier to understand for the reader and it easier
to maintain.

>>> If it works, we have closures. If it doesn't I fail to see what you
>>> mean by 'returning procedures'.
>>
>> Hmm, it must be obvious. How could it be so that we have
>> access-to-procedure types, but no procedure types?
> 
> ?? I still do not understand. If memory serves me right, I cannot
> return an access to a local procedure. So?

I merely explained why I consider procedural types necessary. Accessibility
checks are needed for both them and access to procedure. Though for
procedural values they will be much weaker. Downward closures would require
no checks at all.

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