[e-lang] Quick comments needed on tgc draft
david.nospam.hopwood at blueyonder.co.uk
Sat Jun 18 12:34:47 EDT 2005
Ka-Ping Yee wrote:
> Hi, Mark.
> I spent a chunk of this evening drawing up a figure to help illustrate
> the E event processing model. I think you need to insert a figure to
> explain how the stack and queue work before jumping right into the big
> complicated figure with the two communicating vats. This figure is my
> suggestion for what to insert.
> See the attached Inkscape SVG file.
(Inkscape can be downloaded from <http://www.inkscape.org/download.php>
for various platforms.)
> The figure i have in mind has two
> parts, Figure 1a and 1b. To produce Figure 1a, turn on all the layers
> except those with "Queue" in their names. This would have a caption
> such as:
> Figure 1a. In procedural programming languages, each thread of
> execution can be modelled as a stack of execution frames and a
> memory space for objects.
In shared-state concurrent procedural languages, there is only one
memory space for objects. So this should be expressed as:
Figure 1. In procedural programming languages, each thread of
execution can be modelled as a stack of execution frames. There
are also one or more memory spaces for objects, typically either
per-thread, or shared between threads.
> Each procedure call places a new frame
> on the top of the stack, and the frames are processed from top
> to bottom. In a message-passing system, each frame corresponds
> to a message (arrow) and its target (dot).
Terminology issue: do we count systems with multicast or other
multiple-target messaging primitives as message-passing systems, or
is single-target implied unless otherwise specified?
Mark Miller wrote:
> I agree that we need a figure that shows the single-vat situation before
> showing the multi-vat one. However, I don't think it's worth the paper
> real-estate (much more precious than web-page real estate) to split the
> first into 1a and 1b. In your figure, when I turn on only "Queue Outline",
> "Queue Label", "Stack Labels", "Objects", "Queue Frames", and "Frames",
> the result looks like a good combined illustration.
I agree. Minor nit: the object circles look too big.
> I have yet to draw up the big complicated figure in a similar style,
> but i hope to get to that soon. You'll notice that I have flipped
> the message arrows; this is intentional, because I plan to rearrange
> the big figure so that it reads from left to right. I think that
> will make it easier to understand than having it read from bottom to
> top, as it does now.
> I would like to relabel the entities in the big figure as well, which
> would mean also relabeling them in the text. Instead of calling them
> SH, AM, and XL, I would like to use concrete names such as Account,
> Manager, and Display respectively. If feasible I would even like to
> use method names "setBalance" and "balanceChanged" instead of "setStatus"
> and "statusChanged". What do you think?
I also don't much like the SH/AM/XL names. It would be slightly better if
a different (say sans-serif) font were used to indicate names of entities,
maybe including vats.
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the e-lang