Re: How come Ada isn't more popular?

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

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> (Of course, the call stack is not quite a stack anymore, if
>>> upward closures are allowed!)
>>
>> Depends. Just yesterday I've been imagining a system which basically
>> uses a stack, but when passing a "closure" upwards, copies parts of
>> the stack to the heap.
>>
>> Chicken scheme I think, also uses a stack (in som unusal ways), but
>> still has closure.
>
> Well, yeah, that's the sort of thing I mean by "not quite a stack".

Ah yes, of course. I did understand "not quite" as a cute way to say
"actually the stack is a linked set of frames in the heap", but now I
understand that you indicated your awareness of the various twists
this issue can take (or can be made to take).

> It's sort of like a stack, except some more-recently-pushed parts of
> it need to survive longer, so the implementation copies things
> to the heap, or allocates activation records in the heap in the
> first place, or <various implementation strategies>.

Excactly. :-)

>
>>> It seems to me "inward" and "outward" closures would be clearer
>>> terminology, for what are normally called "downward" and "upward",
>>> respectively.
>>
>> What you call outward closures are just closure.
>
> Well, if a language supports both inward and outward (or downward and
> upward, of you prefer), then people say it supports "full closures".

> It doesn't make a lot of sense to support the outward/upward ones
> without also supporting the inward/downward ones, too.

Yes. I think the whole upward/downward magic talk is simply due to the
fact that there is a case when people don't want GC and have a
traditional stack and therefore do something like closures the cheap
way: Closure data stays valid as long as the stack is not popped. This
is the way downward closures come into the world. 

>
>>... There was a
>> discussion at comp.lang.functional which convinced me, that closure
>> should better be called procdures...
>
> Yes, I saw part of that discussion.  Yes, "closure" really just means
> "procedure".  We use "closure" (or "lexical closure") to emphasize the
> fact that a "procedure" includes some environmental information in
> addition to just the code.

Which in a mathematical sense should be the default. If I say 

 - let a = ...
 - let f(x) = a * proolify (x) ^ a

and later (much later) say something like


 - let's call the coefficient (k1 * k7 ^ p4) a.

nobody (no mathematician) would expect f to change.

> "Closure" also emphasizes that there's something interesting about that
> environment -- namely, that NESTED procedures may be passed around the
> place (whether inward only, or both inward and outward).

As should be the norm.

>>... (because it's rathe the natural way
>> how things should work) and what is presently called downwards closure
>> should better be called somthing different, like, say stack bound
>> procedures (to indicate that their lifetime depends on the stack).
>
> Perhaps.  Pascal programmers just call them "procedural parameters".

Even if they aren't passed around at the moment? Shouldn't a parameter
be something passed to a procedure call? 

Regards -- Markus