Sunday, September 24, 2006

Small updates

I haven't posted for a few days so I thought I would just make a quick update. I am currently putting together some notes so that I can start building the action language metamodel. Naturally, you can't model what you don't understand and until I get a grip on this thing there's just not much to model. The good news, though, is that I'm making a lot of progress which I will post shortly.

I have been reading, re-reading, re-re-re-reading every little detail in the SMALL language paper and putting together some notes. As I progress I am finding a number of issues left, intentionally or not, as "exercises for the student".

Primitive processes such as "attribute write", "object create", etc. are pretty clear. But then you see something like "Compute Volume" (figure 6.16.1 on page 23) with an input data flow labeled "N" and an output labeled "Volume". Okay...

Clearly, somewhere inside that process, is the simple v = l * w * d expression. But we see that there will be one (l, w, d) for each Crate object - thus the N on the input. There's no N on the output! But the example doesn't work if we output only one v, so N must have been intended. Now we could say that the action language interpreter automatically binds the output to an object reference since it sees that the input flow carries an object reference. But what happens if we have an process that inputs multiple <...>N flows - each from a different class? Do we merge the output somehow? Or what if we really did intend to output a single value unassociated with any object reference? My point is that there is a lot of room for ambiguity here and the SMALL paper does not spell any of this out.

Now that's just one example. This paper is replete with missing pieces - all due respect to the authors! So I will make my best effort to fill them in, present some notes, and see what you all think.

2 comments:

Leon Starr said...

Right, I see that. But I don't see any definition of "scope of iteration" in the paper. I know what it means intuitively, but how is it enforced in the language? What are the rules?

Leon Starr said...

It all makes sense as you put it. What bothered me in this particular area was the apparent disparity in the original definition of guards and how they are actually used in the example. It seems that object references flow through the guards - not just the boolean set/not set. That being the case, the flow split example makes sense. Do you agree that the object references are flowing through the guard/control flows?