Parser treatment of expressions

[dlk]

Hi,

Presumably a jack expression like 'x + y / z - 2' is to be semantically interpreted left-associatively,
like '((x + y) / z) - 2', bearing in mind that all jack binary operations have the same precedence.

So now, when outputing parser xml for 'x + y / z - 2', should one have

<expression>
   <term>
      <identifier> x </identifier>
   </term>
   <symbol> + </symbol>
   <term>
      <identifier> y </identifier>
   </term>
   <symbol> / </symbol>
   <term>
      <identifier> z </identifier>
   </term>
   <symbol> - </symbol>
   <term>
      <integerConstant> 2 </integerConstant>
   </term>
</expression>,

or

<expression>
   <expression>
      <expression>
         <term>
            <identifier> x </identifier>
         </term>
         <symbol> + </symbol>
         <term>
            <identifier> y </identifier>
         </term>
      </epression>
      <symbol> / </symbol>
      <term>
         <identifier> z </identifier>
      </term>
   </expression>
   <symbol> -  </symbol>
   <term>
      <integerConstant> 2 </integerConstant>
   </term>
</expression>

The code examples in project 10 seem not to have any instances of
unparenthesized expressions containing more than two terms.

Is there an option to the provided Jack compiler that makes it output
an xml lexical or syntactic parse of input file, rather than going all the
way to VM code?

Generally I find it a bit annoying that the need to compare parse output
with the specific XML format restricts one's parser to stay very close to the
surface syntax...

[cadet1620]

dlk wrote

The code examples in project 10 seem not to have any instances of
unparenthesized expressions containing more than two terms.

From chapter 9:

Order of evaluation and operator priority Operator priority is not defined by the language, except that expressions in parentheses are evaluated first. Thus an expression like 2+3*4 may yield either 20 or 14, whereas 2+(3*4) is guaranteed to yield 14. The need to use parentheses in such expressions makes Jack programming a bit cumbersome. At the same time, the lack of operator priority makes the writing of Jack compilers simpler.

Generally I find it a bit annoying that the need to compare parse output
with the specific XML format restricts one's parser to stay very close to the
surface syntax...

Keep in mind that this is course is designed to guide students with very little programming experience to a specific compiler design so that they can get it written in two weeks, which is an impressive accomplishment. Back in the late 70s it took us a semester to write an assembler, albeit in assembly language. (The final project was for our assembler to assemble itself.)

--Mark

[dlk]

Thanks, Mark!

Not having the text I missed the subtlety that the order of operations is completely undefined for the language (!!!), and merely thought that all the binary operations were of the same precedence; but I assumed left associativity.

I guess that 'makes the writing of Jack compilers simpler' in that no matter what order of operations the compiler implements for cases without explicit parenthesis, the compiler is right!

- Dan