Re: Inline VALOF

[Denis A Nicole <dan@xxxxxxxxxxxxxxx>]

On Wed, 13 Dec 2006, P.H.Welch wrote:

> 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?

I've used it for testing a compiler...

I also agree that the lexical structure, while natural, is painful.  

Perhaps the strongest reason for keeping it is essentially David May's.  
The danger is that without the discipline of a strict "inline" definition
of a function, "function creep" will set in and we'll lose the much more
important semantic properties of occam functions. Also, if (as we 
must) we retain the ability to "inline" in the AST, not being able to do 
it in the source language makes the transformation harder to document and 
understand.
 
We already reason about a (not very) executable superset of occam with 
output guards; I guess that's an essential feature of refinement to a 
distributed implementation. I'm not sure it's worthwhile introducing 
another disconnect between abstract and concrete occam just to help the 
lexers.

I've always hated the asymmetry between IF and ALT. Why are IF guards 
tested in lexical order? Shouldn't that be a PRI IF? William would 
probably have merged ALT and IF, depriving us of the syntactic sugar of an 
obvious nondeterminism flag.

I think demanding PRI SEQ would be a step to far.

Happy Christmas,

Denis A Nicole              WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan
School of Electronics       Email: dan@xxxxxxxxxxxxxxx
       & Computer Science   Phone: +44 23 8059 2703
University of Southampton   Fax:   +44 23 8059 3045
SO17  1BJ
United Kingdom