false or null = null? [message #1754038] |
Tue, 14 February 2017 05:23  |
Eclipse User |
|
|
|
Hi
I'm trying to understand semantics of the OCL. According to Table A.2 of the OCL Specification:
false or null = null
null or null = null
But it seems that Eclipse OCL returns invalid for the both cases:
transformation Semantics();
main() {
log('false or null = ' + str(false or null));
log('null or false = ' + str(null or false));
log('b() or null = ' + str(b() or null));
}
query b() : Boolean = null;
query str(s : OclAny) : String =
if s.oclIsInvalid() then '<Invalid>'
else if s.oclIsUndefined() then 'null' else s.repr() endif endif;
Here is the output:
false or null = <Invalid>
null or false = <Invalid>
b() or null = <Invalid>
Is it a bug in the Eclipse OCL?
|
|
|
Re: false or null = null? [message #1754046 is a reply to message #1754038] |
Tue, 14 February 2017 07:15   |
Eclipse User |
|
|
|
Hi
No and Yes.
The new Pivot-based Eclipse OCL that prototypes solutions to many specification problems is correct. It has a JUnit sub-test:
ocl.assertQueryNull(null, "let b : Boolean = null in false or b");
The classic Eclipse OCL that has a number of issues that are too hard to resolve has:
assertResultInvalid("let b : Boolean = null in false or b");
Unfortunately migration to the new Pivot OCL is a still an aspiration for QVTo, which is I think what you are using.
This is an area that changed as a consequence of the observation by the Isabelle researchers that OCL Boolean operations were not idempotent for null. i.e "X = not not X" should be true. OCL 2.4 Boolean is consistently 4-valued, whereas OCL 2.3 Boolean was 3.5-valued, results were always 3-valued, although the inputs could be 4-valued; there was no difference between null/invalid as input; hence I call it 3.5-valued. IMHO the 3.5-valued seems slightly better, although it seems that in practice code that actually uses this corner is dangerous. When I've tried to have a logic that re-uses Boolean to handle explicitly-true, explicitly-false, unspecified, I find that I need to implement logic explicitly.
Regards
Ed Willink
|
|
|
Re: false or null = null? [message #1754050 is a reply to message #1754046] |
Tue, 14 February 2017 07:41   |
Eclipse User |
|
|
|
Thanks for explanation!
We transform OCL expressions to XPath one. At a first sight the implementation was very simple and straightforward. But we examined special cases involving nulls and invalids.
I think that we will prohibit some kinds of the OCL expressions that could return null or invalid. It is a simplest way to guarantee that resulting XPath expressions will have the same semantics.
|
|
|
Re: false or null = null? [message #1754199 is a reply to message #1754046] |
Wed, 15 February 2017 09:26   |
Eclipse User |
|
|
|
Hi
I've got a related question. For example, there is the following constraint in a model:
self.address.city.size() <= 100
It states that the length of the city name specified in the person's address must not exceed 100 symbols.
If either the address is not specified for the person or the city name isn't specified then the constraint will return invalid value. So we have to add extra checks:
self.address->notEmpty() and self.address.city->notEmpty() implies
self.address.city.size() <= 100
Such a checks are complicates constraints. For example in XPath I can just write:
fn:string-length(address/city) <= 100
and it will return true for empty city name. Because fn:string-length is defined for empty sequence. Most of the XPath functions are defined for empty sequences. Some of them return 0 or empty string, the other one returns empty sequence for empty argument.
Are the any plans to define operations and property call expressions for nulls in the OCL specification?
I think that it's very intuitive behaviour if the expressionself.address.city.size() <= 100 will return null or true instead of invalid for the empty address.
|
|
|
Re: false or null = null? [message #1754225 is a reply to message #1754038] |
Wed, 15 February 2017 14:13   |
Eclipse User |
|
|
|
Several programming languages have a safe navigation operator: https://en.wikipedia.org/wiki/Safe_navigation_operator It's very handy and allows to simplify the code.
I think that OCL doesn't need a separate operator. Because nulls are already automatically cast to empty collections in such expressions:
And also some logical operators already return nulls for null arguments.
Maybe I misunderstand something but I guess that it's enough to extend the semantics of all CallExps. For the null-valued source they must return null (or maybe an empty collection) instead of invalid value.
Invalid values are not very useful. If the PropertyCallExp or OperationCallExp may return null, an empty collection, zero, or empty string it's handier.
|
|
|
|
Re: false or null = null? [message #1754274 is a reply to message #1754235] |
Thu, 16 February 2017 05:40   |
Eclipse User |
|
|
|
Hi
I've tested safe navigation operators and they work! As I see I can check CallExp::isSafe property to check whether the navigation is safe.
What is the status of these operators? Will they be added to the specification? And when it is planed to migrate QVTo to the Pivot OCL? Will QVTd be based on th Pivot OCL?
Thanks
|
|
|
Re: false or null = null? [message #1754339 is a reply to message #1754274] |
Thu, 16 February 2017 13:46  |
Eclipse User |
|
|
|
Hi
QVTd is already based on the Pivot OCL.
Unless someone volunteers to do it for me, I guess QVTo migration might be a year or two away.
In principle a next OMG OCL could be based on auto-generation from the same models from which Eclipse OCL is auto-generated. But there is a lot of work to remove Eclipse-isms and bad design decisions before the models can sensibly be part of a neutral standard.
Unfortunately, I am practically the only person working on OMG OCL, OMG QVT, Eclipse OCL, Eclipse QVTd, so my progress is consistently disappointing.
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.03550 seconds