5 ms·

I'm not sure that's fair. If you have objects that escape downwards (so X calls Y, y creates some item i, i gets returned to X) then you can't have a stack. i m

I'm not sure that's fair. If you have objects that escape downwards (so X calls Y, y creates some item i, i gets returned to X) then you can't have a stack. i may be overwritten at the next call of anything else, as the stack grows over it. I guess they do escape analysis and where items are provably local, stack allocate them. If not, plonk them on the heap. A call frame is an object like any other, so they go on the heap. This allows you to create closures.

Joker_vD 6y ago
See also: https://en.wikipedia.org/wiki/Man_or_boy_test https://en.wikipedia.org/wiki/Man_or_boy_test
Someone 6y ago
I got the stack reference from https://eprints.illc.uva.nl/383/1/PP-2010-04.text.pdf https://eprints.illc.uva.nl/383/1/PP-2010-04.text.pdf, which says: “Dijkstra’s quest to generalize led him to use the well-known concept of a stack (i.e., a continuous portion of computer memory) as a run-time object, rather than a mere compile-time object as was the case in Samelson and Bauer’s ALCOR compiler.” Digging deeper, I found https://www.illc.uva.nl/Research/Publications/Reports/MoL-2009-12.text.pdf https://www.illc.uva.nl/Research/Publications/Reports/MoL-20... (worth reading, IMHO) which indicates Samuelson and Baur used a stack to parse expressions and generate machine code for them, not for assigning memory locations. So, I agree with you it can’t have been as simple als I implied. I doubt they would have plonked anything on the heap, though, because languages of the time didn’t have a heap (FORTRAN certainly didn’t), and the language Samuelson and Baur wrote didn’t even allow functions to call other functions.
- throwaway_pdp09 6y ago
  I was unclear I'm afraid, I was elaborating on your comment about lisp allocating madly, so lisp and not programs in general. Moving to a stack costs, in that you can't do some things, per my original comment. You gain efficiency for what you can do though. > used a stack to parse expressions and generate machine code for them Prob this https://html.duckduckgo.com/html?q=dijkstra%20shunting%20yard%20algorithm https://html.duckduckgo.com/html?q=dijkstra%20shunting%20yar... which I thought came from dijkstra but your digging suggests not, didn't know! (edit: it did https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm) infix -> rpn which matches a stack very well (can evaluate as an interpreter, or emit code as a compiler. Not very efficient but it works). Edit: much credit for digging and reading before posting, wish I could give you several upvotes for that.

Joker_vD 6y ago

See also: https://en.wikipedia.org/wiki/Man_or_boy_test https://en.wikipedia.org/wiki/Man_or_boy_test

Someone 6y ago

I got the stack reference from https://eprints.illc.uva.nl/383/1/PP-2010-04.text.pdf https://eprints.illc.uva.nl/383/1/PP-2010-04.text.pdf, which says: “Dijkstra’s quest to generalize led him to use the well-known concept of a stack (i.e., a continuous portion of computer memory) as a run-time object, rather than a mere compile-time object as was the case in Samelson and Bauer’s ALCOR compiler.” Digging deeper, I found https://www.illc.uva.nl/Research/Publications/Reports/MoL-2009-12.text.pdf https://www.illc.uva.nl/Research/Publications/Reports/MoL-20... (worth reading, IMHO) which indicates Samuelson and Baur used a stack to parse expressions and generate machine code for them, not for assigning memory locations. So, I agree with you it can’t have been as simple als I implied. I doubt they would have plonked anything on the heap, though, because languages of the time didn’t have a heap (FORTRAN certainly didn’t), and the language Samuelson and Baur wrote didn’t even allow functions to call other functions.

throwaway_pdp09 6y ago
I was unclear I'm afraid, I was elaborating on your comment about lisp allocating madly, so lisp and not programs in general. Moving to a stack costs, in that you can't do some things, per my original comment. You gain efficiency for what you can do though. > used a stack to parse expressions and generate machine code for them Prob this https://html.duckduckgo.com/html?q=dijkstra%20shunting%20yard%20algorithm https://html.duckduckgo.com/html?q=dijkstra%20shunting%20yar... which I thought came from dijkstra but your digging suggests not, didn't know! (edit: it did https://en.wikipedia.org/wiki/Shunting-yard_algorithm https://en.wikipedia.org/wiki/Shunting-yard_algorithm) infix -> rpn which matches a stack very well (can evaluate as an interpreter, or emit code as a compiler. Not very efficient but it works). Edit: much credit for digging and reading before posting, wish I could give you several upvotes for that.