1. Expression Delimiters
Gordon stated his position to make single-tic delimiters be optional. John Cosley identified the issue with \r... which requires a space to delimit constructs, which is confusing because expressions may also contain spaces. Bruce identified that variable/constant names could be named LLH, which makes for at least confusing interpretation contexts. Tom identified a concern about invested work in existing parsers, and that the cost of making these constructs optional may be very high. Bruce identified that error detection is near impossible during parse-time in these situations, causing errors to be deferred to later in the process which is aggrevating to customers using these tools.

Tony identified the concern of optional expression delimiters as 'simplicity vs ease of parsing'. AI1 to Tom, John, Bruce, Greg, Doug and anyone else with concerns, to review the existing parser support and scope broadly the impact of this change, to determine if there is such a large infrastructure cost on this change as to make it prohibitive.

2. section 5.5
Gordon voiced concern that table 1 'primitive terms' is too large a set, for instance '+' and '-' shouldn't be here. This resulted in several areas of discussion:

Confusion with the examples of 'integer', in particular 5.0 and 1.066e3, especially in regards to 'reals'. While these values may be interpreted as integer values, the constructs themselves represent real numbers and should be identified as such, with a mechanism to interpret/cast them to integers in context. [AI2] tony remove these definitions as examples of integers.

Are sigref_expressions truly primitive terms, or something resolved by expression processor? The potential complexity of these expressions, and the use of operators in these constructs (+,-, []) indicated to the Working Group that the use of these operators needs to be identified in table 3, and at least the sigref groups should be removed from table 1. [AI3] to tony.

Also Gordon raised concern that ':' is potentially ambiguous in expressions - is it a name delimiter or a conditional expression operator? Tony took [AI4] to review and consider the ambiguity.

In regards to sigref_expressions, the [ ] operator was reviewed. Current understanding... or perhaps perception... is that there are two operators in this construct, .. and space. Bruce identified that the use of spaces to create lists is not obviously defined in the current spec. [AI5] to tony to review.

However, the use of space as an operator in this context is of concern in the context of expressions, as the current definition of dot1 extensions is intended to allow replacement of literal numeric values with at least constants, possibly constant expressions, and possibly variable expressions. As expressions contain space, there is an ambiguity here with the use of space as a set-operator. This raised the notion of using commas here to delimit list-values. {AI6] Tony again will consider the comma operator in lists.

Finally this created a long discussion about "constants", and whether they ever really are in STIL. Because constants are declared in Variable blocks, which may be named, the value of the constant cannot be determined until the complete resolved context of a pattern has been established. This means that these constructs are not resolvable until very late in the processing (to resurrect a user-issue previously identified). But even more it limits the interpretation of all things until the selection of "constants" is established. This was
not the intent of this feature, as there is really no differentiation between a constant expression and a variable expression at this point.

The Working Group discussed the requirement to change the semantics of the unnamed, global Variable block, to contain elements, potentially all constructs supported here, that are allowed to be defined only once. In this way, these definitions cannot be replaced by 'local' named definitions. This allows these declarations to be applied as compile / parse -time values - at least for the constants - which allows at least a mechanism to create true constants and constant expressions from these declarations. [AI7] to tony to define this behavior.

John raised two points about table3 -

-. Use of sigref with operators. This doesn't make sense because these references don't currently have logical behavior defined with them, and/or the expressions created don't have a time. This is confusing in this context. The request is for a set of logic interpretation rules for sigrefs to be defined.

-. John raised a question about the lack of a shift operator. Greg indicated that we don't have a user requesting this construct at this time, no identification of a requirement for such an operation. If such a requirement is identified then we should define the operator but at this point if it's not needed, don't include it.

3. open issues:
integer-to-wfc, wfc-to-integer
Tony identified that \d is a better solution to this issue.

John agreed that this is a better syntax.

Meeting ended at 11:23