Eclipse Community Forums: OCL » false or null = null?

Home » Modeling » OCL » false or null = null?

false or null = null? [message #1754038]

Tue, 14 February 2017 00: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 02: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 02: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 04: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 expression

self.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 09: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:

self.address->notEmpty()

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 #1754235 is a reply to message #1754225]

Wed, 15 February 2017 10:50

Eclipse User

Hi

The Pivot OCL has safe navigation operators: http://www.eclipse.org/modeling/mdt/ocl/docs/publications/OCL2015SafeNavigation/SafeNavigation.pdf

It is integrated into the editors where the warnings are useful. They were also irritating until I added the support for guards such as "(x <> null) implies x.,,," You need to use a recent milestone build.

OCL mostly has a "nulls are bad" policy. Xpath has a "nulls are good" policy. I find OCL distinctly better. Your suggestion would make nulls good which would completely change the language.

Regards

Ed Willink

Re: false or null = null? [message #1754274 is a reply to message #1754235]

Thu, 16 February 2017 00: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 08: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

Previous Topic:	Xtext and OCL references
Next Topic:	Extend data types from the Standard Library in UML model

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Apr 23 23:34:48 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter