Terminology for 'turns'

[johnjbarton johnjbarton]

We have lots of terminology for compiler-ish things, not so much for runtime things.

What would you call the event turn that registered the entry point for the current turn?  For example, if a click handler is running a call stack how might I refer to the turn that ran the addEventListener function that registered the click handler?

jjb

[Peter van der Zee]

I would still call it the call. But you're probably looking for a name like "caller". Fwiw, "turn" didn't exactly make me associate with what you described. And I guess "registration-call" is too long :) </bikeshedding>

- peter

--
--
http://clausreinke.github.com/js-tools/resources.html - tool information
http://groups.google.com/group/js-tools - mailing list information
 
---
You received this message because you are subscribed to the Google Groups "js-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to js-tools+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John J Barton]

By 'turn' I mean the entire tree of function calls, starting with the entry point and (if the turn is over) ending with the entry point (or ending with the exception handler?). By tree of function calls I mean a tree created by recording each function call in a call stack and branching when ever we call twice from the same function.

By entry point I mean 'event-handlers' and any other functions that can begin a 'turn'. These include the outer functions of JS <script> tags and the functions passed to or created by setTimeout/setInterval.

So "registration-call" doesn't make sense to me, but "registration-turn" would. Another option would be "cause" but we generally need two things to cause a turn, both registration and an event.

[Phil Booth]

Registration context?

Origin context?

Origin timeslice?

[johnjbarton johnjbarton]

Origin-turn could be an option. 

I'd avoid "context" as too generic and implying state where time is involved. Plus at least V8 uses "context" to mean "runtime state".

Timeslice implies time but I think "turn" is much more in line with JavaScript's runtime model. From the point of view of the JS machine, we don't get slices of time, we are either running a turn or we are not.

[Salman Mirghasemi]

Origin-call-site.

[John J Barton]

Hmm. From the various suggestions involving "call" I guess I have a different mental model or failed to communicate mine clearly.

The problem I am thinking about here is a user interface for event turns.  Our current implementation has a 'scrubber' bar with a box for every turn. For example, the load event or a click event gets a box. (We also add boxes for warnings and errors).

As you select a turn a panel drops down and gives more info about the turn, including the entry point function and arguments, but also including the turn that added the entry point and any 'potential' turns that could be triggered from entry points added in this turn.

So I am looking for a way to label the incoming and outgoing edges of the event turn graph node corresponding to one event turn. That is why I keep discarding XXX-call and turning them into XXX-turn labels.  That is, I am looking for a label for the turn containing the origin-call-site or registration-call.

Maybe the message is: I should be offering the call-site rather than the turn containing the call site.  (Much harder to obtain unfortunately).

Thanks for all of the input!

jjb

[Brian Burg]

Hello jjb!

I like the turn metaphor as a way of explaining single-threaded event loops, but this might make less sense if parallel arrays gain traction.

I would suggest "event" or "event handler" but those are quite overloaded. "Callback" might be a good truce between accuracy and intuitiveness. Callbacks are registered/unregistered or installed/uninstalled. (In my Timelapse [0] project, I have recently started calling these things "event loop inputs" internally and "actions" externally to disambiguate from DOM events, but this is not any clearer to the end-user than "turns".)

You might find some inspiration in how Whyline [1] presents causality diagrammatically (hint: doesn't label edges), and how LaToza's Reacher tool [2] visualizes call graphs. Both projects use different styles of arrows to connote direct calls and causality. If one node says `addEventListener("click", …`) and the other node indicates it's a "click" callback at some other point in time, then explicit labeling is unnecessary, IMO. Of course having the precise callback install site is preferable, but showing causality at a callback/turn-level is still super useful.

[0] www.github.com/burg/timelapse/

[1] http://www.cs.cmu.edu/~NatProg/whyline.html, http://www.cs.cmu.edu/~NatProg/whyline-java.html

[2] http://www.ics.uci.edu/~tlatoza/papers/vlhcc2011.pdf