[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inline VALOF
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
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
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.
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