Yet another strike against the current AA implementation

[Georg Wrede]

Andrei Alexandrescu wrote:
> Georg Wrede wrote:
>>>> I can't believe you brought it up as anything else but jesting 
>>>> (maybe you are and I'm not getting it).
>>
>> Having looked into things, it turns out I'm the one that now suspects 
>> you of jesting.

Could it be that you're looking at this too much through the eyes of a 
compiler developer? With souce code that can include templates, it 
should be no surprise that a programmer can write a file which results 
in preposterous stack needs. This is certainly the case with C++, for 
example.

> What I referred to was inferring a thread's actual stack requirements 
> from one trace of its run. 

Of course you'd give different input data, a little like you give 
different input data to your unit tests.

> That's just untenable.

Agreed, IF there's a possibility of recursion happening, the variation 
in input data is not guaranteed, etc. But for practical purposes (read: 
most of my programs, and presumably those of the other programmers'), 
the situation is different.

For a particular application, we expect some explicit or implicit 
constarints on the input data. We also know (er, expect) whether (and to 
what extent) there will be recursion. Additionally (as with any 
real-life application), we accept that if the input data goes wild, the 
application /doesn't/ have to cope with it. (Making nuke proof apps 
where reasonably good is sufficient, is just gratuituous work.)

For example, a robust application, instead of accepting and coping with 
*anything*, instead has *documented limitations*. IMHO, that is the 
right way to "fix infinity problems". Not demanding limitless stack for 
all kinds of programs.

>>> Maybe I'll have to dig up prior art, or something. Clearly I'm not 
>>> qualified to properly defend the validity of this idea.
>>
>> There is prior art, by the truckload. A /very/ short slide show here: 
>> http://zope.stackless.com/StacklessEuroPy.ppt
>>
>> I'd kill to get that in D.
> 
> Interesting, just you can't claim you were talking about that all along. 
> I mean, come on! You say one thing that was untenable, and now you come 
> up with a different one that is. And you were right all along?

I was actually talking about *two* things. If you remember, I was 
talking about measuring actually used stack depth. Then I got the idea 
of having separate stacks for threads. Two separate things in a post.

(Now that I think more about it, I must have heard about stackless 
Python somewhere. But as I've seen others do, this time I, too, believed 
I invented something that I've actually seen somewhere.)

>> And about your comments on stack size, seems regular Python has an 
>> in-built limit on recursion, at 1000 deep. That should be 
>> diametrically opposite your stance on stack size.
> 
> Python has apparently set a maximum to have a guarantee it won't crash 
> when given a certain minimum stack size. That's nice, but I'm not quite 
> seeing how that's opposite to what I said in this discussion.

Nope. It's because

  - They don't want the entire computer thrashing each time some idiot 
has a typo in his recursive algorithm.

  - They genuinely don't think you usually need preposterous levels of 
recursion. And if you do, then just change the limit.

Python is for Real Computers (as opposed to Windows). There it's polite 
to make your apps (here, the Python interpreter) have some decency as to 
how much resources they take. The idea is that there are hundreds of 
other users, and dozens of daemons running critical apps, round the clock.

If developers didn't know (by measurement or analysis) the reasonable 
stack size needed, there would be no mobile phones, no set-top boxes 
with hard disks, no GPS receivers, no digital PBX appliances, no solid 
state firewalls, no ADSL boxes, no programmable calculators......

Dammit, any pocket calculator that has parenthesis buttons needs a 
stack. And that stack space is predermined by the manufacturer.

I'm still maintaining that the stack space needs of regular applications 
are much less than people tend to think. Last time I checked, you ran 
out of stack on a name brand calculator with just ten levels of 
parentheses. That's not much. On the other hand, in real life, not too 
many people in the world have ever seen a calculator run out of stack space.