Issue 2203: Notification Constraint language problem (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section 2.4.3 (final bullet) says: * When a boolean operand is used in an arithmetic operation, it is treated as weakly-typed CORBA::Long. This is semantically very dubious. What value is used for TRUE and FALSE? 1 and 0 perhaps? This results in "TRUE + TRUE == 2" producing a match and "TRUE / FALSE" producing a divide by zero error! Resolution: Added text at end of 3rd bullet from top of new page 45 Revised Text: Actions taken: November 11, 1998: received issue November 16, 1999: closed issue Discussion: Synopsis: DSTC questioned the final bullet in section 2.4.3 which states that, with respect to the constraint grammar, boolean values are treated as weakly typed CORBA::Longs when used in arithmetic operations. In their message raising this issue, DSTC complained that this is semantically weak, although they added that some members of DSTC actually like this feature. DSTC proposed two alternative solutions to this issues: 1) Get rid of the feature by changing the bullet to state that usage of boolean values in an arithmetic operation is a type mismatch error, causing whatever "match" operation within which they are used to fail 2) Clarify that the value of TRUE and FALSE, when used in arithmetic operations, correspond to 1 and 0 respectively Disposition: We at NEC like this feature, and feel it is both required and standard with the way CORBA treats boolean values. We feel it's required because it allows the constraint grammar to handle expressions that combine the results of boolean comparisons, which we feel is typically expected of a constraint grammar (e.g., ($.fruit = apples) + ($.color = red) + ($.kind = macintosh) > 2) Furthermore, while we have no fundamental opposition to explicitly stating that TRUE=1 and FALSE=0, we don't necessarily feel it's necessary because section 12.3.1 of CORBA alread states that "Boolean values are encoded as single octets, where TRUE is the value 1, and FALSE is 0." Essentially, we feel CORBA already defines TRUE to be 1 and FALSE to be 0, however we are not opposed to adding such a statement into Notification if folks feel it's necessary. VOTE: This vote is being subdivided into 2203a and 2203b. Voting YES on 2203a means to accept option 1) described above. Voting YES on 2203b means to accept option 2) described above. Voting NO means to do nothing. It is invalid to vote YES on both 2203a and 2203b. NOTE: Only 2203b passed End of Annotations:===== Return-Path: To: issues@omg.org Cc: notif_service-rtf@omg.org Errors-to: devnull@dstc.edu.au Reply-to: notif_service-rtf@omg.org Subject: Notification Constraint Language problem X-face: *A\_v+D,~Jx_g]`m,s61-x|*;H4hgZeE= Section 2.4.3 (final bullet) says: * When a boolean operand is used in an arithmetic operation, it is treated as weakly-typed CORBA::Long. This is semantically very dubious. What value is used for TRUE and FALSE? 1 and 0 perhaps? This results in "TRUE + TRUE == 2" producing a match and "TRUE / FALSE" producing a divide by zero error! The motivation seems to be to support counting of a list of predicates, as in section 2.4.7: $type_name == 'MOVIE' and (('groucho' in $.starlist) + ('chico' in $.starlist) + ('harpo' in $.starlist) + ('zeppo' in $.starlist) + ('gummo' in $.starlist)) > 2 Proposed solution: Some of us at DSTC like the feature, while others are more inclined to have a stricter type system and eliminate more nonsense matches at the expense of losing the feature. There are (at least) two possible solutions. 1) Get rid of this feature. Change this bullet to read: "When a boolean operand is used in an arithmetic operation a type mismatch occurs and the match fails" 2) Clarify that the value of TRUE and FALSE for arithmetic operators are 1 and 0 respectively. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::