Re: Inline VALOF

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

Hey All,

We didn't really mean to stir up a deep discussion!  Though that's always
interesting and fun, :).

We'd still like the question Adam asked answered:

  * has anyone ever used the VALOF construct in any past or present
    occam-coded project ... other than in the mandated way for a FUNCTION
    body ... and other than for teaching what a VALOF construct does?

So far, we have had no replies ... which we take to mean "no".  Will this
change?

		    ----------------------------------

Dipping a toe into the deep discussion ...

> - Adam finds it difficult to parse the syntax - and this is likely to lead
> to errors in doing so. We will all need to rely on the parser getting it
> right so anything that makes it easier and less error-prone is a good reason
> to make a change.

I find it difficult to write the syntax!  This is solely due to feeling
very uncomfortable about line indents that don't move neatly in and out
by regular amounts.  For me, this (rather than the difficulty or otherwise
of parsing by the compiler and other tools) is a good argument for change.
If nobody has ever used it, that is a really powerful point for abolition.

I've not seen all of David May's reply on this list?  I'd not considered
that removing VALOFs meant we removed the formal representation of FUNCTION
calls as inlined substitution.  That is a powerful point in favour of
retention.

		    ----------------------------------

> - Denis suggests a more familiar notation and that is likely to result in
> programmers using it correctly and improving the chance of their programs
> being correct - that seems like a good reason to make a change.

occam expressions are very powerful: side-effect free, able to be reasoned
about simply, able to be parallelised trivially.  Conditional expressions
would increase that power and I've always fancied them - e.g.:

  <boolean-exp> -> <exp>, <exp>

Indeed, we put "->" into the compiler ages ago as a reserved symbol with
the above in mind ... but never got around to it.  Then, instead of:

  IF
    urgent
      delay := 1*weeks
    TRUE
      delay := 2*weeks
    
we could write:

  delay := urgent -> 1*weeks, 2*weeks

which kind of thing happens quite a lot!??

I don't see any semantic problem with conditional expressions - the two
expressions on the RHS must have, of course, matching types.

		    ----------------------------------

Put above aside!!  Are there any "yes" answers to Adam's question?

Thanks,

Peter.