Replies: 1 comment 1 reply
-
Yes, the display is a separate thread. The reason your recursive procedure never runs out of stack is that the (only) recursive call is the last thing the procedure does, and Berkeley Logo does tail call elimination, which means that it essentially reuses the same stack frame instead of growing the stack. If it were embedded recursion (with more code after the recursive call) then it would indeed eventually run out of stack space. About the edge-of-screen behavior, you can tell Logo what you'd like it to do: |
Beta Was this translation helpful? Give feedback.
-
Hey! Found this repo today linked a couple hops from an older Papert/MIT page. Got the software running and made a few super-interesting (to me) experiments. Much appreciation for everyone's efforts here.
This code:
Actually runs and draws things (as seen in the screenshot), a similar program, without
wait
ended up quickly filling the screen, due to the wrapping behavior, I guess.This was surprising to me, because my intuition was that the recursion on
t
would happen 'immediately' and eventually overflow some stack, or at the very least hang and not give the program a chance to draw anything or otherwise continue to run.My question:
What is the right way to think about how this is working?
Does
t
compile to (or somehow otherwise operate as) something that hands control back to the application outside the interpreter to let the turtle and GUI update? How often? Each call tot
? Or periodically in time?Or is it better thought of that the turtle is on another 'thread' (literal machine thread or otherwise) consuming commands on some queue being fed by the interpreter generally and
t
specifically?Or is some other mental model better?
Similar question about
forever
in LOGO, how can that work?Thanks in advance for any insights - having a lot of fun and learning a lot over here.
Beta Was this translation helpful? Give feedback.
All reactions