Clarification on asymmetry of atom and push/pull

[12ay....@gmail.com]

In "Naming Functions", I'm trying to reason through why deref-ing a atom is a pull.

From the three examples shown: put message on queue, HTTP requests, pulling data from another thread, I can think of three commonalities (which don't apply to atoms):

- you do not share memory with the resource you're pushing & pulling from

- push/pull operates on data that should be serializable

- indirection is used -- your function doesn't know where data is coming from or going to (the pull-source or push-destination may be an argument to the function)

- these operations can fail

Is this thinking on the right path?

Can you also help clarify why writing to an atom is a push? Is it because an atom has properties of IRef where watches are often used as push functions?

[Zach Tellman]

I had to double-check there wasn't a typo or something, but in the book it says explicitly that deref-ing an atom is *not* a pull.  I'm going to assume that was what you meant.

The basic idea here is that each thread (or something which is thread-like) has a scope of data it can see, which encompasses things in lexical scope (function parameters, let-bound variables, values which have been closed over) and things in global scope.  Since those values are "at hand", when we use them we are simply transforming data we already have.  This includes pulling out the value enclosed within a reference.

However, if our currently visible data doesn't suffice, we must rely on someone else to update a shared reference to give us the data we need.  When we request that someone do it for us, that's a pull.  When we do it for someone else, that's a push.

Does that make sense?  I'm expanding on these ideas in the last chapter, but I want to make sure readers aren't confused on this point before they reach the end of the book.

Zach

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/78cc3763-9d75-4557-8a91-295be3b44d45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[12ay....@gmail.com]

You're correct about the assumption, sorry for the typo!

I think the clarification helps. Taking that meaning and applying to an atom: De-refing is *not* a pull because it always returns  whatever value the atom currently points at (in scope). There's no requesting or waiting for the atom's value to become ready/available.

Taking this a bit further, by this definition, deref-ing a future is considered a pull?

On Tuesday, February 6, 2018 at 3:12:52 PM UTC-8, Zach Tellman wrote:

I had to double-check there wasn't a typo or something, but in the book it says explicitly that deref-ing an atom is *not* a pull.  I'm going to assume that was what you meant.

The basic idea here is that each thread (or something which is thread-like) has a scope of data it can see, which encompasses things in lexical scope (function parameters, let-bound variables, values which have been closed over) and things in global scope.  Since those values are "at hand", when we use them we are simply transforming data we already have.  This includes pulling out the value enclosed within a reference.

However, if our currently visible data doesn't suffice, we must rely on someone else to update a shared reference to give us the data we need.  When we request that someone do it for us, that's a pull.  When we do it for someone else, that's a push.

Does that make sense?  I'm expanding on these ideas in the last chapter, but I want to make sure readers aren't confused on this point before they reach the end of the book.

Zach

On Sat, Feb 3, 2018 at 6:13 PM <12ay....@gmail.com> wrote:

In "Naming Functions", I'm trying to reason through why deref-ing a atom is a pull.

From the three examples shown: put message on queue, HTTP requests, pulling data from another thread, I can think of three commonalities (which don't apply to atoms):

- you do not share memory with the resource you're pushing & pulling from

- push/pull operates on data that should be serializable

- indirection is used -- your function doesn't know where data is coming from or going to (the pull-source or push-destination may be an argument to the function)

- these operations can fail

Is this thinking on the right path?

Can you also help clarify why writing to an atom is a push? Is it because an atom has properties of IRef where watches are often used as push functions?

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clojure+unsub...@googlegroups.com.