[Oberon] Oberon-07 formal context free

[Jörg]

Michael

> and I think the actual ORP implementation is even LL(k) [or even LL(1)?]

It depends how we define an "LL(1) implementation". Generally, ORP has only ONE variable "sym" that represents the symbol just read. And all IFs are based on this ONE symbol. As it is only ONE symbol (and not an array of k symbols) you could say, ORP is coded as LL(1).

There are however cases where this "sym" is temporarily stored for later use:
In term(), SimpleExpression() and expression0().
You always store the operator symbol, parse the second operand and generate the correct operation based on the stored symbol afterwards.

One could say, it's just a code optimization:
At the time we read the symbol "ORS.times", we principally know that is a multiplication. So one lookahead is fine. But as the code generation is later, we store the operator.
In theory, you could copy the whole code several times and call the correct ORG.RealOp(ORS.times, x, y), ORG.IntRel(ORS.eql, x, y) in the end, instead of storing the symbol in "op" or "rel" and simply calling ORG.RealOp(op, x, y), ORG.IntRel(rel, x, y) afterwards.

But I actually don't know whether this ORP code is really an LL(k) case or still is an "LL(1) implementation with temporary symbol storage".

br
Jörg