Opened the meeting with a review and discussion of Paul's doc on

lockstep changes to simplify the lockstep behavior and make execution

more clean and not subject to semantic definitions. After some

discussion, the central concept of this proposal was identified as the

definition of a "merged macro" intended to be instantiated once across

parallel lock-stepped patterns (as opposed to standard macro/procedures

which need the capability of being instantiated uniquely for each

unique context of application), and some mechanism of resolving the

naming contexts across potentially different domains used by each of the

parallel patterns; either supporting resolution of name-clashes by

allowing an explicit domain-reference::name, or other mechanism to

support remapping operations simply and directly.

[AI1] Tony and Greg to work through a proposal for this behavior.

[AI2] Tony get Paul's frame doc and make the examples compliant and

represent the proposal above.

Paul identified an additional issue with synchronizing patterns of

different length; the shorter pattern still needs to execute macro

calls in order to maintain the overall chained-scan-load, Paul

presented the notion of a "padding" pattern to serve this function, and

a request for a repeat-option to apply this padding pattern as

necessary to fill to the longest pattern count of the parallel

patterns. It was proposed that the current Extend construct (which

pads at the Vector level only at the moment) would be extended to

perform this behavior.

[AI3] Tony to define the Extend additions for this behavior.

Rohit raised an issue about retaining the value of variables between

PatternBursts. Currently, expectations are that an InitialValue is

re-asserted each time a variable (with an initial value) comes into

existence. This would prohibit values from persisting through

non-contiguous references to the domain. A proposal to define an

additional attribute or a modifier attribute to the InitialValue

behavior was considered to address this issue.

[AI4] Tony to define and propose something to address this.

Rohit raised a (final, for this meeting) concern about general

variable access - reading and writing behaviors, and the need for

general capabilities here. The Working Group beleives that this is in

place at this point.

Tony requested closure on draft document D15, to clear change-bars and

move to draft document D16 to address these remaining issues. Doug

motioned to accept D15 and start work on D16, Greg seconded, and the

WG agreed with no negative ballots.

Tony reviewed an issue raised at the last meeting about allowing

access to enumerated values as constants outside of the enumeration

context. A proposal was made to define a WFCConstant type, like

IntegerConstants, to support this behavior without extending access to

the enumerated namespace. Greg stated his preference for this

additional construct because of the potential confusion and unintended

collisions with enumerated names if they are generally visible.

Tony proposed reducing the restrictions on enumerated

values. Currently, a variable identified to contain enumerated values

can *only* contain enumerated values. The proposal here would allow

this variable to contain other, potentially non-enumerated, values,

most notably, previously-defined WFCConstants without requiring them

to be redefined as part of the enumerated values. This was accepted by

the Working Group, with Tony to define an attribute like

'AllowNonEnumValues' to indicate when a variable is intended to be

so-unconstrained.

[AI5] Tony to define the WFCConstant and non-restricted-value attr.

A brief review of the fail feedback status occurred, but Jason was not

present and all that was identified was no change in status. Because

Paul R. was present, Tony highlighted that this topic was under review

for Paul to bring back to the CTL group because there is CTL interest

in this issue as well.

Meeting adjourned at 11:02 PDT.

Next phone meeting Apr 24.