(1) Constants and Enums

The prior requests to open up access to enumerations resulted in an

environment where enumerations were pretty much identical to constants

from a scoping/access/name-resolution perspective. Therefore a new

proposal has been made to define WFCConstants (as the

SignalVariable-enum equivalent) and to remove enums from the language,

replacing them with IntegerConstant and WFCConstant types.

All present unanimously agreed to this proposal.

[AI1] to Tony to add WFCConstant, and remove enums from the spec.

(2) Fail data

No progress as Jason was not present. AI remains [AI2].

(3) LockStep

No progress as Greg and Tony didn't spec a proposal. AI remains [AI3].

(4) MaxIntegerSize construct

Peter raised 3 specific concerns about this construct:

(*) why just integers? why not other quantities as well?

(*) is the value 32? or 32 and a sign bit? what about signed vs

unsigned?

(*) why in the header?

Bruce raised two concerns

(*) why in the header?

(*) does this even belong in the language?

Discussion:

Bruce identified that while this might be a "nice flag", it doesn't

change the job of his STIL reader/interpreter -- which must process

any STIL that it can. A STIL interpreter must be responsible for

trapping it's own exceptions, including if it sees a number that's

"too big" (or too small, for that matter). Putting this flag into the

STIL file doesn't change the job that the interpreter already must do.

Peter identified that because this flag is inserted by the WRITER

(since it's part of a STIL file), the writer may need to make

ASSUMPTIONS about the behavior of a program. For instance, an integer

value may never be processed during interpretation to be larger than,

oh, say, 1 bit (because all integer values in the program are

initialized to 0). But during EXECUTION of that program, an integer

may assume much larger values. This means that the context where the

size of the integer isn't an issue during interpretation, but during

run-time. Stating a single size value may cause a program to be

identified as "not processable", overly constraining the application

of that program.

In the end, it is the understanding of this Working Group that the

issue of supporting values that exceed the minimum required by the

dot-zero standard, is a function of the readers and run-time

environment, which must flag overflow issues ANYWAYS, and that writers

(which may also rely on integer sizes > 32 bits to generate their

data) won't change what the readers and run-time environments must

support by adding this statement.

This proposal was vetoed in this Working Group.

Meeting adjourned at 10:32 PST.

Next phone meeting May 8