[e-lang] Quick comments needed on tgc draft

David Hopwood 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 mailing list