I'm learning TLA+ using VS Code and vscode-tlaplus plugin instead of TLA+ Toolbox. Now I have this TLA file where I define some constants:
---- MODULE test ----
EXTENDS TLC, Integers, Sequences
CONSTANTS Capacity, Items, ValueRange, SizeRange
ItemParams == [size: SizeRange, value: ValueRange]
ItemSets == [Items -> ItemParams]
===
I would like to set the following in the cfg file:
SPECIFICATION Spec
CONSTANTS
SizeRange = 1..4
ValueRange = 0..3
Capacity = 7
Items = {"a", "b", "c"}
But this causes the following error:
TLC threw an unexpected exception.
This was probably caused by an error in the spec or model.
See the User Output or TLC Console for clues to what happened.
The exception was a tlc2.tool.ConfigFileException
:
TLC found an error in the configuration file at line 5
It was expecting = or <-, but did not find it.
So far I only found this workaround:
.tla
---- MODULE test ----
EXTENDS TLC, Integers, Sequences
CONSTANTS Capacity, Items, ValueRange, SizeRange
ConstSizeRange == 1..4
ConstValueRange == 0..3
ItemParams == [size: SizeRange, value: ValueRange]
ItemSets == [Items -> ItemParams]
====
.cfg
SPECIFICATION Spec
CONSTANTS
SizeRange <- ConstSizeRange
ValueRange <- ConstValueRange
Capacity = 7
Items = {"a", "b", "c"}
So, it seems useless to define a CONSTANT.
I'm doing something wrong, or is this the expected behaviour?
Thanks
This is the expected behavior. TLC only supports very specific TLA+ expressions as values assigned to constants in the CFG file. I agree it would be nice if more powerful expressions were supported.
This is generally handled by convention: you have one "good copy" SpecName.tla TLA+ spec which isn't directly model-checkable by TLC, and a second MCSpecName.tla TLA+ spec which overrides various definitions in the first to make it model-checkable, plus defines constant values. So in your case you'd have:
Test.tla:
---- MODULE Test ----
EXTENDS TLC, Integers, Sequences
CONSTANTS Capacity, Items, ValueRange, SizeRange
ConstSizeRange == 1..4
ConstValueRange == 0..3
ItemParams == [size: SizeRange, value: ValueRange]
ItemSets == [Items -> ItemParams]
====
MCTest.tla:
---- MODULE MCTest ----
EXTENDS Test
ConstSizeRange == 1..4
ConstValueRange == 0..3
====
MCTest.cfg:
SPECIFICATION Spec
CONSTANTS
SizeRange <- ConstSizeRange
ValueRange <- ConstValueRange
Capacity = 7
Items = {"a", "b", "c"}
You can see this convention used throughout the TLA+ examples, such as Paxos. It's actually quite a good convention, freeing you to write your "good copy" spec to more accurately reflect reality instead of conforming to the whims of the model checker. For example, in your good copy spec you might have a now variable which defines the current time; it could be Real-valued, and advance by an arbitrary positive Real value after every Tick action. In your MC spec you would override now and Tick to use some subset of the Naturals.
The below module declares a set of numbers that are in the range 10 to 99 that are divisible by 2 only once and call it NumbersThatDivideBy2Once. At the end it declares a theorem that the constant input is a subset of NumbersThatDivideBy2Once.
--------------------------- MODULE TestModule ---------------------------
EXTENDS Naturals
CONSTANT input
Numbers == { n \in Nat : n > 9 /\ n < 100 }
DividesBy2(n) == (n % 2) = 0
DividesBy2Once(n) == DividesBy2(n) /\ ~DividesBy2(n \div 2)
NumbersThatDivideBy2Once == { n \in Numbers: DividesBy2Once(n) }
THEOREM input \subseteq NumbersThatDivideBy2Once
=======================
How can I check if this theorem holds for a given input? If I run a model check with a provided set of numbers as input, even if some of those numbers are not part of NumbersThatDivideBy2Once I still get no errors.
Give your theorem a name,
THEOREM T == input \subseteq NumbersThatDivideBy2Once
Go to the "Model Checking Results" tab, and in "Evaluate Constant Expression" introduce T, in order for it to be evaluated.
Your model checker needs to be told what to do with the specification file, which is essentially a just collection of mathematical definitions.
In "normal use" you want to provide TLC a temporal formula representing your specification (usually given the nameSpec in the specification file). You introduce it in the "model overview" tab, under "what is the behaviour spec?". And that is what TLC uses to perform model checking.
In this case you don't have that. So just keep the option "no behaviour spec" and, as indicated above, specify in the "Model Checking Results" tab the constant expression you want to evaluate.
I have the following spec:
------------------------------ MODULE Group ------------------------------
CONSTANTS People
VARIABLES members
Init == members \subseteq People
Next == members' = members
Group == Init /\ [][Next]_members
=============================================================================
(I simplified this spec to the point where it's not doing anything useful.)
When I try to run it through TLC, I get the following error:
In evaluation, the identifier members is either undefined or not an operator.
The error points to the Init line.
When I change the Init line to:
Init == members \in People
it validates fine.
I want the former functionality because I mean for members to be a collection of People, not a single person.
According to section 16.1.6 of Leslie Lamport's Specifying Systems, "TLA+ provides the following operators on sets:" and lists both \in and \subseteq.
Why is TLA+ not letting me use \subseteq?
While that is a valid TLA+ expression, TLC can only assign next-state values to a variable x by the statements x' = e or x' \in S. See section 14.2.6 for details. This holds for the initial assignment, too. In your case, you probably want members \in SUBSET People.
I feel really stupid, and feel like I'm missing something.
I've basically got two files:
module.pl for the universal logic rules (meant to be reusable)
state.pl one for the current scenario
In the module file (module.pl) I've declared:
inside(Food,Eater,T) :-
isTime(T),
injestEvent(InjEvent),
justAfter(T,InjEvent),
actorOfEvent(InjEvent, Eater),
objectOfEvent(InjEvent, Food).
Q1) I've had to declare all those other predicates with singleton variables (in the same file), just to stop module.pl complaining they don't exist:
isTime(_T).
justAfter(_Time,_Event).
actorOfEvent(_Event, _ActorOfEvent).
objectOfEvent(_Event,_ActorOfEvent).
Is that right?
Q2) I can't use those predicates like justAfter/2 my other file without it saying:
Local definition of user:justAfter/2 overrides weak import from module
How can I use the predicates I've imported from my module, rather redefining it?
Prolog modules were designed to hide auxiliary predicates. They don't provide a concept of interface that allows separating predicate declarations from predicate definitions. That's why the compiler complains if you export predicates that are not defined. From your description, I assume you tried something like:
----- module.pl -----
:- module(module, [
inside/3, isTime/1, injestEvent/1, justAfter/2, actorOfEvent/2, objectOfEvent/2
]).
inside(Food,Eater,T) :-
isTime(T),
injestEvent(InjEvent),
justAfter(T,InjEvent),
actorOfEvent(InjEvent, Eater),
objectOfEvent(InjEvent, Food).
---------------------
which results in:
?- [module].
ERROR: Exported procedure module:justAfter/2 is not defined
ERROR: Exported procedure module:isTime/1 is not defined
ERROR: Exported procedure module:injestEvent/1 is not defined
ERROR: Exported procedure module:objectOfEvent/2 is not defined
ERROR: Exported procedure module:actorOfEvent/2 is not defined
true.
You attempted to workaround this error by adding local definitions. But this just result in the second problem you describe. When you do something like:
?- use_module(module).
You import all the predicates exported by module, including those that you want to define in state.pl. Therefore, the compiler warns you, when loading state.pl, that this file is overriding those predicates. E.g. with:
----- state.pl -----
isTime(1).
injestEvent(injEvent).
justAfter(1, injEvent).
actorOfEvent(injEvent, eater).
objectOfEvent(injEvent, food).
--------------------
we get:
?- [state].
Warning: /Users/pmoura/Desktop/state.pl:1:
Local definition of user:isTime/1 overrides weak import from module
Warning: /Users/pmoura/Desktop/state.pl:2:
Local definition of user:injestEvent/1 overrides weak import from module
Warning: /Users/pmoura/Desktop/state.pl:3:
Local definition of user:justAfter/2 overrides weak import from module
Warning: /Users/pmoura/Desktop/state.pl:4:
Local definition of user:actorOfEvent/2 overrides weak import from module
Warning: /Users/pmoura/Desktop/state.pl:5:
Local definition of user:objectOfEvent/2 overrides weak import from module
true.
Although these are warnings and not errors, calling the inside/3 predicate will not give you what you want:
?- inside(Food,Eater,T).
true.
Where are the bindings?!? Let's trace the call to highlight the cause:
?- trace.
true.
[trace] ?- inside(Food,Eater,T).
Call: (8) module:inside(_2508, _2510, _2512) ? creep
Call: (9) module:isTime(_2512) ? creep
Exit: (9) module:isTime(_2512) ? creep
Call: (9) module:injestEvent(_2804) ? creep
Exit: (9) module:injestEvent(_2804) ? creep
Call: (9) module:justAfter(_2512, _2806) ? creep
Exit: (9) module:justAfter(_2512, _2806) ? creep
Call: (9) module:actorOfEvent(_2804, _2510) ? creep
Exit: (9) module:actorOfEvent(_2804, _2510) ? creep
Call: (9) module:objectOfEvent(_2804, _2508) ? creep
Exit: (9) module:objectOfEvent(_2804, _2508) ? creep
Exit: (8) module:inside(_2508, _2510, _2512) ? creep
true.
The trace makes it clear that the "state" predicates are being called in the wrong context.
A clean solution is to use Logtalk objects instead of Prolog modules. Logtalk extends Prolog and supports most systems, including SWI-Prolog. It supports interfaces/protocols as first-class entities (which solve the first problem you mention) and supports inheritance and calling predicates in their usage context (which solves the second problem). You could use e.g.
----- common.lgt -----
:- object(common).
:- public([
inside/3, isTime/1, injestEvent/1, justAfter/2, actorOfEvent/2, objectOfEvent/2
]).
inside(Food,Eater,T) :-
% call the next predicates in "self", i.e. in the
% object that received the inside/3 message
::isTime(T),
::injestEvent(InjEvent),
::justAfter(T,InjEvent),
::actorOfEvent(InjEvent, Eater),
::objectOfEvent(InjEvent, Food).
:- end_object.
----------------------
and then represent "state" as:
----- state.lgt -----
:- object(state, extends(common)).
isTime(1).
injestEvent(injEvent).
justAfter(1, injEvent).
actorOfEvent(injEvent, eater).
objectOfEvent(injEvent, food).
:- end_object.
---------------------
A quick test (after installing Logtalk):
$ swilgt
...
?- {common, state}.
...
true.
?- state::inside(Food,Eater,T).
Food = food,
Eater = eater,
T = 1.
As a bonus, you can define as many "state" objects as you need. You can also have default definitions for the "state" predicates in the common object. These will be inherited and used when the "state" objects don't provide a definition for a particular predicate. For example, let's add to common the clause:
objectOfEvent(injEvent, drink).
and delete (or comment out) the clause objectOfEvent(injEvent, food). from state. Save and reload and retrying the query will give you:
?- {*}. % abbreviation for Logtalk's make
% Redefining object common
...
% Redefining object state
...
true.
?- state::inside(Food,Eater,T).
Food = drink,
Eater = eater,
T = 1.
If needed, you can also dynamically create new state objects instead of defining them in source files. For example:
?- create_object(s2, [extends(common)], [], [isTime(42), ...]).
This may not be the answer you were looking for but this is also the case where the best answer is to use the right tool^H^H^H^H encapsulation mechanism for the job. Your programming pattern is also a quite common one (and one of the reasons Logtalk was developed).
It's very simple to add a basic form of 'object orientation'.
Let's say we have a clause in a module logic:
:- module(logic, [inside/4]).
% apply the rule to a specified module (expected to be a state object)
inside(M,Food,Eater,T) :-
M:isTime(T),
M:injestEvent(InjEvent),
M:justAfter(T, InjEvent),
M:actorOfEvent(InjEvent, Eater),
M:objectOfEvent(InjEvent, Food).
and we have a lot of state objects pertinent: in a file state1.pl
isTime(10).
injestEvent(eat).
justAfter(10, eat).
actorOfEvent(eat, mick).
objectOfEvent(eat, food).
and in a file state2.pl
isTime(20).
injestEvent(sleep).
justAfter(20, sleep).
actorOfEvent(sleep, everyone).
objectOfEvent(sleep, dream).
then a possible session:
?- [logic].
true.
?- s1:consult(state1).
true.
?- s2:consult(state2).
true.
?- inside(s1,Food,Eater,T).
Food = food,
Eater = mick,
T = 10.
?- inside(s2,What,Who,T).
What = dream,
Who = everyone,
T = 20.
A small generalization, worth to try:
inside(M,Food,Eater,T) :-
resolve(M),
M:isTime(T),
...
where resolve/1 could be
resolve(M) :- var(M) -> current_module(M), catch(M:isTime(_),_,fail) ; true.
this trick enable 'browsing the objects':
?- inside(M,X,Y,Z).
M = s2,
X = dream,
Y = everyone,
Z = 20 ;
M = s1,
X = food,
Y = mick,
Z = 10 ;
false.
An alternative to CapelliC is the use of Prolog dicts. They have been introduced by SWI-Prolog and since release 1.3.0 they are also available in Jekejeke Prolog. If the receiver is not needed, one can simply use an underscore.
File state1.pl:
:- module(state1, [isTime/2, injestEvent/2, justAfter/3,
actorOfEvent/3, objectOfEvent/3]).
:- reexport(logic).
_.isTime() := 10.
_.injestEvent() := eat.
_.justAfter(10) := eat.
_.actorOfEvent(eat) := mick.
_.objectOfEvent(eat) := food.
File state2.pl:
:- module(state2, [isTime/2, injestEvent/2, justAfter/3,
actorOfEvent/3, objectOfEvent/3]).
:- reexport(logic).
_.isTime() := 20.
_.injestEvent() := sleep.
_.justAfter(20) := sleep.
_.actorOfEvent(sleep) := everyone.
_.objectOfEvent(sleep) := dream.
File logic.pl:
:- module(logic, [inside/4]).
M.inside(Food,Eater) := T :-
T = M.isTime(),
InjEvent = M.injestEvent(),
InjEvent = M.justAfter(T),
Eater = M.actorOfEvent(InjEvent),
Food = M.objectOfEvent(InjEvent).
To make the logic also visible in state1 and state2 use reexport/1. This allows sending a message to state1 or state2, but nevertheless a method from logic will be processed. Here is an example run:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.19)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- T = state1{}.inside(Food,Eater).
T = 10,
Food = food,
Eater = mick.
?- T = state2{}.inside(Food,Eater).
T = 20,
Food = dream,
Eater = everyone.
The exports of isTime/2, injestEvent/2, etc.. will go away with the upcoming release 1.3.1 of Jekejeke Prolog when we have made ('.')/3 call-site aware. But the result for Jekejeke Prolog is the same:
Jekejeke Prolog 3, Runtime Library 1.3.0
(c) 1985-2018, XLOG Technologies GmbH, Switzerland
?- T = state1{}.inside(Food,Eater).
T = 10,
Food = food,
Eater = mick
?- T = state2{}.inside(Food,Eater).
T = 20,
Food = dream,
Eater = everyone
Disclaimer: this is for a homework assignment
I'm a coq noob, so I hope this is not a repeat question. I /have/ looked at this question, but my question seems to be unanswered still.
I have the following premises:
P \/ Q
~Q
I need to prove:
P
My coq code so far:
Section Q5.
Variables Q : Prop.
Goal P.
Hypothesis premise1 : P \/ Q.
Hypothesis premise2 : ~Q.
I get the following error when I try to execute the line Goal P.:
Error: The reference P was not found in the current environment.
These are the solutions that I was able to come up with:
Replace Variables Q : Prop. with Variables P Q : Prop.. The problem with this is that P will be assumed as a premise, which it is not
Add Variables P. before the goal declaration. This results in a syntax error.
Am I missing something? I don't seem to be able to figure this out.
The proper solution is 1, and the problem you are expecting is wrong.
When you write:
Variable P: Prop.
You are not assuming that P is inhabited (or, that "P holds"), but only that there exists a proposition named P, a "statement" whose validity is not considered here.
This is very different from writing:
Variable p: P.
Which assumes that there is a proof "p" that the type "P" is inhabited (if P has type Prop, p is a proof of the proposition P), and thus assumes that P is true.
Also, the reason why:
Variables P.
results in a syntax error is that you need to provide a type for each variable introduced (Coq can't figure it out magically when there is no information leading the type inference engine).
So it is perfectly fine to begin your script as:
Section Q5.
Variables P Q : Prop.
Hypothesis premise1 : P \/ Q.
Hypothesis premise2 : ~Q.
Goal P.