BlueBook BlockContext --why the sender is nil

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
tty
Reply | Threaded
Open this post in threaded view
|

BlueBook BlockContext --why the sender is nil

tty
 
If you look at this (or attached, if it doesn't show up inline) picture  from Eliot Miranda's  Closure's Part I discussion ,  the naive <cough> me </cough> would spend two days wondering whey there are no senders.
After all, its obvious that  --sender: nil means that there are no senders.





From Squeak By Example, page 55 in the discussion of pseudo-variables, "nil is the unique instance of the class UndefinedObject".

Which makes perfect sense.

One of these days, I will get past paragraph 4 on this Closures Discussion, but boy, there are a lot of things going on under the hood there. (:

Thanks for your patience as I try to grok this stuff.

cheers.

tty.

factblock080607.jpeg (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BlueBook BlockContext --why the sender is nil

Eliot Miranda-2
 



On Sun, Dec 15, 2013 at 4:28 PM, gettimothy <[hidden email]> wrote:
 
If you look at this (or attached, if it doesn't show up inline) picture  from Eliot Miranda's  Closure's Part I discussion ,  the naive <cough> me </cough> would spend two days wondering whey there are no senders.
After all, its obvious that  --sender: nil means that there are no senders.

Assuming you're not joking, that's not what it means at all.  The sender points to the sender context *until* it is returned from.  We're inspecting a block, which got created in the Doit context for the expression [:n| ....].  And that DoIt context is the home context of the [:n|...] block.  The DoIt context returned its result (the [:n|...] block) to whatever the sender context was.  But when the DoIt context returned that result the DoIt context's sender was nilled, to indicate that it had been returned from.  So by the time the [:n|...] block was inspected its home context's sender was nil.

Have you tried reading through the BlueBook's VM section?  That's an excellent presentation of the VM's operational semantics (its how I leaned).  The only problem is that it presents BlueBook blocks, not closures.  It would be great to rewrite it as a 32-bit closure VM -- when ever time allows ;-)







From Squeak By Example, page 55 in the discussion of pseudo-variables, "nil is the unique instance of the class UndefinedObject".

Which makes perfect sense.

One of these days, I will get past paragraph 4 on this Closures Discussion, but boy, there are a lot of things going on under the hood there. (:

Thanks for your patience as I try to grok this stuff.

cheers.

tty.




--
best,
Eliot
tty
Reply | Threaded
Open this post in threaded view
|

Re: BlueBook BlockContext --why the sender is nil

tty
 
Thank you Eliot.

That makes sense.

I did read the BlueBook VM section and have copious notes, but the mental picture in my mind is flawed obviously.

I will re-read that with your reply in mind.

Thank you for your time.

tty

---- On Mon, 16 Dec 2013 11:04:50 -0800 Eliot Miranda<[hidden email]> wrote ----




On Sun, Dec 15, 2013 at 4:28 PM, gettimothy <[hidden email]> wrote:
 
If you look at this (or attached, if it doesn't show up inline) picture  from Eliot Miranda's  Closure's Part I discussion ,  the naive <cough> me </cough> would spend two days wondering whey there are no senders.
After all, its obvious that  --sender: nil means that there are no senders.

Assuming you're not joking, that's not what it means at all.  The sender points to the sender context *until* it is returned from.  We're inspecting a block, which got created in the Doit context for the expression [:n| ....].  And that DoIt context is the home context of the [:n|...] block.  The DoIt context returned its result (the [:n|...] block) to whatever the sender context was.  But when the DoIt context returned that result the DoIt context's sender was nilled, to indicate that it had been returned from.  So by the time the [:n|...] block was inspected its home context's sender was nil.

Have you tried reading through the BlueBook's VM section?  That's an excellent presentation of the VM's operational semantics (its how I leaned).  The only problem is that it presents BlueBook blocks, not closures.  It would be great to rewrite it as a 32-bit closure VM -- when ever time allows ;-)







From Squeak By Example, page 55 in the discussion of pseudo-variables, "nil is the unique instance of the class UndefinedObject".

Which makes perfect sense.

One of these days, I will get past paragraph 4 on this Closures Discussion, but boy, there are a lot of things going on under the hood there. (:

Thanks for your patience as I try to grok this stuff.

cheers.

tty.




--
best,
Eliot