Proposal for generation changes...

["Dan Romaine" <dan.romaine@paradigm-works.com>]

Currently when one field has dependency on another field, to be safe, we
must specify generation order explicitly.  There is a default generation
order (order of declaration), as well as other sytax which effects order
(like when inheritance), but the most robust solutions for eVC and the like
of code written and tested in one environment but then integrated in another
is to use the value() method OR keep gen () before () syntax.  Most people
who code up large E code environments run into issues with generation order.
I propose two changes:

1) We create a syntactical notion of new passes through generation.  This
would provide a way for one piece of code (an eVC perhaps) to run its own
static analysis, reductions, and set scalars flow completely independent of
other sections of code.  This feature would create predictability and
reliability that does not exist today.  When e-code is run in a different
environment than you wrote it in, your generation order might be
re-arranged.  Verisity admits this freely, and I think we need to find a
solution.

2) We either add a new semantic for unidirectional implication or change the
existing bi-directional imply.  Most users would like to see the imply
operator (=>) effect generation order.  I think we need both a
unidirectional and a bidirectional imply.  Both could boil down to the
appropriate OR statements, but the unidirectional could also add an order
constraint.  I think the goal should be easily coded user intent and
readability.  I'm not sure what the best solution is, but there are times
when the order of generation is thought to be one way, but it becomes
convoluted and the imply holds true, but the unintended field is in control
of distribution.  Here is a quick example:

x: uint;
y: byte;

keep x < 10 => y < 200;

In this case, a small range of x [0..9] has a large range for y [0..199],
but a large range of x [10..MAX_INT] has a small range of y [200..255];

If x is generated first, the distribution of values is even over
[0..MAX_INT] by default, therefore there is a strong chance that y will be
in the [200..255] range.  If Y is generated first, the distribution of
generated values changes completely.  Both examples are OK, but the intent
needs to be more clear than the simply order of declaration.

So in short, there is a difference between dependency and order.  Order is
our mechanism to guarantee dependency.  If order is not explicitly coded,
there is room for unintended results.  I think we need to reduce the
ambiguity and add more precision, specifically to the imply operator.

 - Dan Romaine
Paradigm Works, Inc.



PS. Are we on for a Feb. 23 meeting?  That day is good for me.