Previous Up Next

12  Trees

finished, except the 2 function stubs

This is the intermediate representation. It is described in [App98b, Section 7.1]. It is some sort of abstract machine language. The module does not contains code, it is basically a datatype declaration, corresponding to the abstract syntax at the user level, now at an intermediate level.

To do:
The function notRel and commute are stubs. They occur (not implemented) in the NJ-SML code. What is the use of the size-variable?
commute is mentioned at page 175, but in the context of the Canon-module.

What’s the use of the function notRel and commute? They showed up in the interface provided in the SML code fragments, but I found no description. There’s also a Canon.commute-function. The ones here are currently stub.

[Jump] Why is there a list of labels for Jump?

This will be needed later, for dataflow analysis.

[Sequence] The tree language has a binary sequence operator Seq. Now, what is the “associativity” of the operator, i.e., given a list of tree expressions e0,…, en−1, are they to be represented as Seq(e0,Seq(… Seq(en−2, en−1)…)) or the other way round. Is there a preference intended or doesn’t it matter at all?

The semantics as described on page 151 gives no clue. In general I would assume that sequential composition is semantically associative, so it doesn’t matter whether we associated it to the right or the left. In the parser, for the concrete syntax, we defined the “;” to be right-associative, which is kind of standard, I guess. On the other hand, the trees feature a binary constructor Eseq, which is more in line with associating a list of statements to the left: the last element of a sequence sticks out in that it generated the value for the whole sequence.

The pictures in [App98b], though, seem to indicate that at least Seq is intended to associated to the right, and so this is what I will do. The last element that provides the value will be treated separately.

e1 ; e2 ; e3 ; e4 => Eseq(Seq(e1,Seq(e2,e3)), e4)

Previous Up Next