🚀 go-pugleaf

In article <3921@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP I wrote:

  Algol-60 does not allow an assignment within an expression, and there
  would be no ambiguity using '=' for both assignment and equality.  This
  is because the designers of Algol-60 had the good sense to make it a
  statement language.  They then used for equality the only reasonable
  symbol, and for assigment they used the left-pointing arrow, to capture
  the notion that something flowed from the RHS to the LHS.

In article <367@sequent.cs.qmc.ac.uk> keithc@qmc.ac.uk (Keith Clarke) writes:

  Algol 60 doesn't allow assignments within expressions, but
  there would too be an ambiguity, because it allows multiple
  assignment:

  (1) p :=  q = r
  compare q and r, put the answer in p.

  (2) p := q := r
  put the value of r into q and also into p.

  Parsers normally don't use type information to sort out
  syntactic ambiguities, so it doesn't really matter if = isn't the
  operator for comparing booleans; it is certainly the operator
  for something!

Thank you, Keith, I should have mentioned this point.  A modern parser
would indeed perceive a syntactic ambiguity here.  Back in 1959, such
things were not worried about overmuch (there are other syntactic
ambiguities in the original Report), provided there was some way to
resolve the problem.

The semantic resolution, of course, is that EQUALS returns a Boolean
result but cannot take Boolean operands, so we have

	p,q,r all  Boolean: p ASSIGN q ASSIGN r
	p,q,r none Boolean: ditto
	p Boolean, q,r not: p ASSIGN q EQUALS r

Other combinations are illegal.

My post should have made it more clear that "ambiguity" was intended to
mean something stronger that "context-free syntactic ambiguity".  Sorry.
And, of course, there would be a true ambiguity if EQUALS took Boolean
operands, as many Algol compilers permit.