Re: Software fault forces Ford recall

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Rick Beton wrote:

> So my assertion is that the hard part is agreeing on the new grammar.
> The easy part is implementing it.

That's true.  If the alternative syntax maintained the philosophy of
the classic syntax, we might be able to get away just by modifying
the tokeniser in the compiler - not even touch the parser (maybe).
Once parsed, it would be trivial to output either syntax - so we would
have a translator between the two versions.

I suggest that both concrete syntaxes (syntaces?) be allowed.  We could
have a flag to the compiler to say which one to expect - or maybe that
could be deduced fairly quickly and automatically?

> ... it turned out much easier to implement a grammar that recognised ';' as
> the end-of-statement marker.

It's not that simple - ";" is also used as a separator in sequential
protocols.  We'd need to change the latter (e.g. to "++" - see below).

Another problem is where to place declarations.  Conventionally, inner block
declarations are done inside the block tokens - e.g:

  if (something) {
    int a, b, c;
    ...  two or more lines of code that uses a, b, c
  } else {
    byte b;
    ...  two or more lines of code code that uses b
  }

whereas occam declarations have the scope of subsequent declarations and
the executable that follows.  That executable may be a compound - i.e. an
inner block.  So, occam declares variables *outside*, and before, the block
tokens (indentation level changes):

  IF
    something
      INT a, b, c:
      SEQ
        ...  two or more lines of code that uses a, b, c
    TRUE
      BYTE b:
      SEQ
        ...  two or more lines of code that uses b

Anyway, translating the above by just introducing {}s instead of indentation:

  if (something) {
    int a, b, c:
    seq {
      ...  two or more lines of code that uses a, b, c
    }
  } (true) {
    byte b:
    seq {
      ...  two or more lines of code that uses b
    }
  }

Will people complain about the compulsory "seq"?  If they want:

  if (something) {
    int a, b, c;
    ...  two or more lines of code that uses a, b, c
  } (true) {
    byte b;
    ...  two or more lines of code that uses b
  }

where SEQ is assumed for multiple lines of executable (unless a "par {...}"
is introduced) and the ":" turned into a ";", then it's a much more difficult
translation job - not just the tokeniser.  Don't like this.

Do we really want the ()s around the boolean expressions - it aligns with
the C-like look-and-feel?  But replicator's look good with it:

  par (i = 0 for n) {
    ...  some process

and:

  alt {
    alt (i = 0 for size in) {
      real64 tmp:
      in[i] ? tmp {                 // this { is needed!
        seq {
	  out ! i ++ tmp;           // ++ is the seqeuntial protocol separator?
	  ...  other book-keeping
	}
      }
    (preCondition) & tim ? after timeout {
      seq {
	panic ! timedOut;
	...  more book-keeping
      }
    }
  }

Just for fun - here's the "delta" process from commstime:

  PROC delta (CHAN OF INT in, out.0, out.1)
    WHILE TRUE
      INT n:
      SEQ
	in ? n
	PAR
	  out.0 ! n
	  out.1 ! n
  :

which might turn into:

  proc delta (chan of int in, out0, out1) {
    while (true) {
      int n:
      seq {
	in ? n;
	par {
	  out0 ! n;
	  out1 ! n;    // ";" is a statement terminator (rather than separator)
	}
      }
    }
  }

I think I prefer the "classic" syntax - 3 lines shorter!  Mind you, we could
re-format the latter as:

  proc delta (chan of int in, out0, out1) {
    while (true) {
      int n: seq ( in ? n; par { out0 ! n; out1 ! n; } }
    }
  }

But this is an invitation to write clever obscure code ...

Also, Rick doesn't like those funny places for "{" - so it ought to be:

  proc delta (chan of int in, out0, out1)
  {
    while (true) 
    { 
      int n: seq ( in ? n; par { out0 ! n; out1 ! n; } }
    }
  }


But, then, there's the one-liner:

  proc delta (chan of int in, out0, out1) { while (true) { int n: seq ( in ? n; par { out0 ! n; out1 ! n; } } } }

that some students will take great pleasure in writing!

Maybe someone will propose a formal syntax over the Christmas festivities?
I still like the proposal aired a few WoTUGs ago to allow "{" and "}"
into occam ... but just fix the tokeniser to treat them as white space.

Happy Christmas,

Peter.