Re: in defense of GC

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:
>> 
>>>> The point is that the programmer is freed from the error prone tedium of
>>>> explicitly managing memory.
>>>
>>> This is a misconception. There are two fundamentally different issues:
>>>
>>> 1. Object scopes
>>> 2. Memory management
>>>
>>> The second issue is less and less relevant as Randy pointed out. The first
>>> issue is always relevant. It is a good design to consider where an object
>>> exists. GC [and upward closures] is an attitude of making everything
>>> potentially global. In fact it is worse than just global. It is "I don't
>>> know where I need that damn thing."
>> 
>> 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?
Scope is defined as the visibility of identifiers. There is now
introduction of global scope in the cas eof returning closures. You
seem to confuse this with lifetime of memory....


>
>> Closures provide exactly the opposite of
>> "making things global". They provide a way for a module (a capsule of
>> knowledge / implementation) to return a method (how to do things)
>> without disclosing the implementation (i.e. keeping up the abstraction
>> barrier).
>
> I have no problem with that. But it is not yet an upward closure when the
> type of the returned object is local.

?. Do you confuse the type of the enclosed objects with the type of
the closure?


Forgive me Dmitry, but I'm on the verge of giving up on you. Your
terminology is, well, unusual. I suggest you read up on some FP and
especially do some and the we restart this argument (or not).


> 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.

If it works, we have closures. If it doesn't I fail to see what you
mean by 'returning procedures'. You seem to be long term proponent for
something you're arguing hard to be bad / not useful / whatever ... --
ahem, fighting yourself :-).


>> I can't believe I even have to spell it out. On the other side -- why
>> do I argue? You're even opposing generics.
>
> Yes I do! (:-))

Yes I notice. That does make you avantgarde, certainly. Even the Java
people learned that there is no live without generics / functors.


>>> This is A) mess, B) sloppy programming, C) impossible model in our
>>> networking distributed relativist world.
>> 
>> There are BTW, even distributed garbage collection algorithms. This
>> probably will enrage you no end? :-).
>
> Yes I know, they are usually called trojans...  (:-))

?.

Regards -- Markus