Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add facility to only check a condition if a type binding is finite #529

Closed
paulch42 opened this issue Apr 13, 2016 · 5 comments
Closed

Add facility to only check a condition if a type binding is finite #529

paulch42 opened this issue Apr 13, 2016 · 5 comments
Labels
enhancement Not a bug, but nice to have
Milestone

Comments

@paulch42
Copy link

When type bindings are employed, a specification cannot in general be executed by an interpreter. The Runtime tab of the Run Configurations in Overture allows pre-condition, post-condition, invariant etc checks to be turned on or off which allows a specification to be executed even if it has infinite type bindings. Unfortunately, if say invariant checks are turned off, they are turned off for the entire model, preventing checks on invariants that do not have infinite type bindings.

Suggested improvement:
The interpreter through static analysis determines, where type bindings are used, if the range is infinite. If so the check is skipped, if not the check is performed. This would allow the interpreter to perform maximal constraint checking while not discourage the use of type bindings.

Doubt the interpreter can always decide if a type binding is finite or infinite, but in that case err on the side of caution and only perform the check if the interpreter can confirm the type binding has a finite range.

@nickbattle nickbattle added the enhancement Not a bug, but nice to have label Apr 13, 2016
@nickbattle
Copy link
Contributor

Type binds can occur anywhere in a specification, not just in pre/post/inv constraints. So turning off (say) invariant checks may avoid problems with invariants, but type bind executions would still fail in the bodies of functions or operations.

I would be a bit uncomfortable about the tool "passing" constraints that otherwise should fail, simply because it knows that it cannot execute them. I can see that it is similar to turning off pre/post/inv checks, but the side effects may be more insidious - besides, a normal function body that includes a comprehension generated from a type bind has to return something, it cannot "skip" that comprehension or return {} or [] etc.

You're right that, in general, we cannot be statically sure about finiteness. The problem cases are infinite types with invariants that make them finite.

Other views?

@paulch42
Copy link
Author

I see, I was only thinking about condition checks outside of the body of a function, without realising the full consequences. I can certainly now see the problems in what I proposed.

@nickbattle
Copy link
Contributor

We can see whether others think it's worth doing anything in this area, but if not, close this issue.

We should note the "feature" (that I didn't know about!) where Overture will allow you to set an integer range specifically to allow integer type binds to return a finite set of values. That worries me too, though it's an interesting approach. It would need to be generalised, if we go this route.

@ldcouto
Copy link
Member

ldcouto commented Apr 13, 2016

I do not support disabling the checks internally. When the user disables the checks or sets an integer bound, they are doing so explicitly and that is the key point, to me.

As for (not) executing type binds, I agree that it's a limitation. There was some work done on connecting the interpreter to a model checker for executing implicit functions. I suppose a similar approach could be tried for type bindings. I'm in favour of any efforts in that direction.

@peterwvj peterwvj added this to the v2.3.10 milestone Jul 1, 2016
@peterwvj peterwvj modified the milestones: v2.4.2, v2.4.0 Aug 29, 2016
@peterwvj peterwvj modified the milestones: v2.4.2, 2.4.4 Oct 4, 2016
@peterwvj peterwvj modified the milestones: 2.4.4, 2.4.6 Dec 2, 2016
@peterwvj peterwvj modified the milestones: 2.4.6, 2.4.8 Mar 3, 2017
@peterwvj peterwvj modified the milestones: v2.4.8, v2.5.0 Jun 5, 2017
@peterwvj peterwvj modified the milestones: v2.5.0, v2.5.2 Aug 10, 2017
@peterwvj peterwvj modified the milestones: v2.5.2, v2.5.0 Aug 10, 2017
@peterwvj peterwvj modified the milestones: v2.5.2, v2.5.4 Sep 11, 2017
@peterwvj peterwvj modified the milestones: v2.5.4, v2.5.6 Nov 9, 2017
@peterwvj peterwvj modified the milestones: v2.5.6, v2.5.8 Dec 11, 2017
@peterwvj peterwvj modified the milestones: v2.6.0, v2.6.2 Feb 16, 2018
@peterwvj peterwvj modified the milestones: v2.6.2, v2.6.4 May 17, 2018
@peterwvj peterwvj modified the milestones: v2.6.4, v2.6.6 Oct 18, 2018
@peterwvj peterwvj modified the milestones: v2.7.0, v2.7.2 Jun 3, 2019
@peterwvj peterwvj modified the milestones: v2.7.2, v2.7.4 Sep 30, 2019
@nickbattle
Copy link
Contributor

I think this idea was effectively rejected, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Not a bug, but nice to have
Projects
None yet
Development

No branches or pull requests

4 participants