gistfile1.txt

# This is what we’re going to break down:
1|  routine {
2|    my.system  ←  ( HTTP.system  clone() )
3|    my.system  cache  ( ‘http://google.com’ )
4|    my.system  cache  ( ‘http://yahoo.com’ )
5|    my.system  process.cached.sites  ()
6|  }

# This is the original routine, broken down with subexpressions on their own lines. Actual lines of the routine
# are numbered; subexpressions appear above the lines they are a part of, with space in the line to account for
# the subexpression itself. Also, the `locals` portion of the lookup is shown.
1|  routine {
 |                            locals  HTTP.system  clone() 
2|    locals  my.system  ←  (                              )
 |                                locals  ‘http://google.com’ 
3|    locals  my.system  cache  (                             )
 |                                locals  ‘http://yahoo.com’ 
4|    locals  my.system  cache  (                            )
5|    locals  my.system  process.cached.sites  ()
6|  }

# We theoretically start by concurrently executing *every* line of the document. In practice, this would not be
# the case, of course, but we’ll pretend we have a magical computer with over nine thousand cores!!1!1! for the
# sake of this example.
# 
# The interpreter cannot know, at this point in time, whether the first subexpression of line 2 modifies the
# result of looking up `locals`; thus, it has to block the subsequent lookups for that same key, until it’s
# determined whether or not that subexpression modifies it.
1|  routine {
 |                           [locals] …
2|   ⇥locals …
 |                               ⇥locals …
3|   ⇥locals …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# We have successfully looked up `locals` on that subexpression in line 2, so we begin looking up `HTTP.system`
# on the result of that. Notice, until we’ve completed looking up `HTTP.system`, the rest of the lines are still
# blocked at the lookup of `locals`—we are still not sure whether `HTTP.system` will be an atomic routine (that
# might modify `locals`.) While there’s the possibility of `locals` being modified, we have to block its lookup
# and not return an ISV for it.
1|  routine {
 |                            locals [HTTP.system] …
2|   ⇥locals …
 |                               ⇥locals …
3|   ⇥locals …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# Now we’ve recognized that the `HTTP.system`, as it exists in the first subexpression on line 2, is not an
# atomic routine—in fact, it’s not a routine at all! Thus, we can know for sure that `locals` has not changed by
# that subexpression, and move on to looking up `my.system` on the outer expression of line 2, while
# simultaneously looking up the next word (`clone`) of the first subexpression.
# 
# Mind you, the rest of the expressions in the routine are still blocked at the result of looking up `locals`;
# because it’s impossible to know if the outer expression of line 2 modifies it until we figure out what
# `my.system` is.
1|  routine {
 |                            locals  HTTP.system [clone] …
2|    locals [my.system]
 |                               ⇥locals …
3|   ⇥locals …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# Having ascertained that `my.system` on line 2 is not an atomic routine, we can presume `locals` to be
# unmodified as of the first subexpression of line 3. Thus we can safely move on to looking up the next word in
# that expression. Of course, the rest of the expressions are still blocked at `locals`; we can’t know if the
# string in line 3 will resolve to a routine that modifies `locals`.
1|  routine {
 |                            locals  HTTP.system  clone [()]
2|    locals  my.system [←] …
 |                                locals [‘http://google.com’]
3|   ⇥locals …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# Having completed the subexpression of line 2, the routine call `HTTP.system clone()` is spun off into a
# parallel routine. The rest of the outer expression of line 2 can’t be completed until the subexpression spits
# back an ISV; so we’re blocked against that.
# 
# At this point, we’re aware that `←` is an atomic routine; thus, we block all further lookups for
# `locals my.system` until that routine ceases execution.
# 
# Having looked up the string on line 3, and discovering that, no, it’s not an atomic routine… it’s just a
# string… we can assume `locals` hasn’t changed before the outer expression on line 3. Thus, we can pay attention
# to the next word. Unfortunately, that word is `my.system`, which we are blocking against (as described above)
# due to the atomic routine executing on line `2`. Thus, we can’t continue executing that line.
# 
# Same as usual, rest of the expressions are blocked against `locals`.
# 
# At this point, execution would ‘halt:’ that is, there is nothing else we can do to interpret the routine,
# because every lookup is blocked by something else, and the only thing going on is us waiting for
# `HTTP.system clone()` to hand us a ‘result.’
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ← ⇥(                                ) 
 |                                locals  ‘http://google.com’ 
3|    locals ⇥my.system …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# The next step is when `HTTP.system clone()` hands us back a value. At this point, we can lookup the last word
# of line 2, the argument to the assignment routine. Again. though, we have to stop everything else at this
# point, until the assignment completes.
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ← [(                                )]
 |                                locals  ‘http://google.com’ 
3|    locals ⇥my.system …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# Finally! Our assignment has completed. We are no longer blocking lookups against `locals my.system`, so line 3
# is able to continue, looking up the new `my.system`. Everything else is still blocked against `locals`, because
# `my.system` has recently changed, and could possibly be an atomic routine that might modify `locals`.
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ←  (                                ) 
 |                                locals  ‘http://google.com’ 
3|    locals [my.system] …
 |                               ⇥locals …
4|   ⇥locals …
5|   ⇥locals …
6|  }

# Since we know `my.system` (the new value) doesn’t modify `locals`, we can begin our next lookup against that.
# Again, it’s a string. Same rules apply as before. At the same time, we’re looking up `cache` on our new
# `my.system`.
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ←  (                                ) 
 |                                locals  ‘http://google.com’ 
3|    locals  my.system [cache] …
 |                                locals [‘http://yahoo.com’]
4|   ⇥locals …
5|   ⇥locals …
6|  }

# We now know that the string in the subexpression on line 4 isn’t a routine that modifies `locals`, so we can
# proceed with the outer expression on line 4. In fact, we’re also already aware of what `locals my.system` is,
# and we’re aware that it can’t be changed, so we can skip that entire lookup; in fact, we can skip all the way
# to needing `cache`, just like on line 3. Since we looked that up in the previous step, we end up in exactly the
# same place as we were last iteration… meaning we can take the values of the subexpressions and hand them to
# `cache` simultaneously.
# 
# At the same time, we know from what we have left to do can possibly modify `locals`; in fact, again, we can
# skip forward to the next unknown bit: `process.cached.sites`.
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ←  (                                ) 
 |                                locals  ‘http://google.com’ 
3|    locals  my.system  cache [(                             )]
 |                                locals  ‘http://yahoo.com’ 
4|    locals  my.system  cache [(                            )]
5|    locals  my.system [process.cached.sites] …
6|  }

# Finally, we’ve reached the point where we’ve spun off both `cache()` calls, and are about to spin off
# `process.cached.sites`:
1|  routine {
 |                            locals  HTTP.system  clone  () 
2|    locals  my.system  ←  (                                ) 
 |                                locals  ‘http://google.com’ 
3|    locals  my.system  cache  (                             ) 
 |                                locals  ‘http://yahoo.com’ 
4|    locals  my.system  cache  (                            ) 
5|    locals  my.system  process.cached.sites [()]
6|  }