I've been hitting the following error in TLA+ toolbox for a few days now in various contexts:
"Attempted to compute the number of elements in the overridden value Nat.".
The following is the simplest module that I've come up with that will reproduce the issue. I've seen some mention of overridden values, but I can't see how I'm doing something in the spec to cause this issue.
Does anyone see the error, or can explain what I'm missing?
-------------------------------- MODULE foo --------------------------------
EXTENDS Naturals
VARIABLE Procs
Init == Procs = 1..5
Next == /\ Procs' = 1..5
Entries == [ i \in Procs |-> [ j \in {} |-> 0] ]
TypeOK == Entries \in [ Procs -> [ (SUBSET Nat) -> Nat ] ]
=============================================================================
When setting TypeOK to the invariant, I get the full error
Attempted to compute the number of elements in the overridden value Nat.
While working on the initial state:
Procs = 1..5
TLC cannot evaluate the set Nat, because it is infinite (see also the overridden module Naturals.tla). Replacing Nat with a finite set via the configuration file is one possible workaround.
After doing so, it turns out that TypeOK is FALSE, because DOMAIN Entries = Procs, and Procs # SUBSET Nat. In other words, the set [ (SUBSET Nat) -> Nat] contains functions each of which has domain equal to SUBSET Nat. Instead, what was probably intended is the set of functions with domain equal to some subset of Nat. This is done below with TypeOKChanged.
-------------------------------- MODULE foo --------------------------------
EXTENDS Naturals
VARIABLE Procs
Init == Procs = 1..5
Next == Procs' = 1..5
Entries == [ i \in Procs |-> [ j \in {} |-> 0] ]
TypeOK == Entries \in [ Procs -> [ (SUBSET Nat) -> Nat ] ]
TypeOKChanged == Entries \in [ Procs -> UNION {[Dom -> Nat]: Dom \in SUBSET Nat} ]
NatMock == 0..6
=============================================================================
and the configuration file foo.cfg:
INIT Init
NEXT Next
CONSTANTS Nat <- NatMock
INVARIANT TypeOKChanged
The output is
$ tlc2 foo.tla
TLC2 Version 2.09 of 10 March 2017
Running in Model-Checking mode with 1 worker.
Parsing file foo.tla
Parsing file ~/tlatools/tla/tla2sany/StandardModules/Naturals.tla
Semantic processing of module Naturals
Semantic processing of module foo
Starting... (2017-10-15 16:00:06)
Computing initial states...
Finished computing initial states: 1 distinct state generated.
Model checking completed. No error has been found.
Estimates of the probability that TLC did not check all reachable states
because two distinct states had the same fingerprint:
calculated (optimistic): val = 5.4E-20
based on the actual fingerprints: val = 1.1E-19
2 states generated, 1 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 1.
Finished in 03s at (2017-10-15 16:00:09)
A proof involving the infinite set Nat can be pursued with the theorem prover TLAPS. See also Sec. 14.2.3 on pages 234--235 of the TLA+ book the section "Don't Reinvent Mathematics".
Related
The following code gives me an error:
Require Import Reals.
Require Import List.
Import ListNotations.
Open Scope R_scope.
Definition C := (R * R)%type.
Definition RtoC (r : R) : C := (r,0).
Coercion RtoC : R >-> C.
Definition lC : list C := [0;0;0;1].
Error: The term "[0; 0; 0; 1]" has type "list R" while it is expected to have type "list C".
But I've defined RtoC as a coercion and I don't see any problems when I use
Definition myC : C := 4.
How do I get Coq to apply the coercion within the list?
Related question: If I enter Check [0;0;0;1] it returns list R, inserting an implicit IZR before every number. Why does Coq think I want Rs rather than Zs?
I'm unsure there is a fully satisfying solution to your question.
Indeed, as recalled in the Coq refman:
Given a term, possibly not typable, we are interested in the problem of determining if it can be well typed modulo insertion of appropriate coercions.
and it turns out that in your example, the term [0;0;0;1] itself is typable as a list R and it is type-checked "in one go"; thereby when the [0;0;0;1] : list C type mismatch occurs, as there's no "backtracking", a coercion can't be inserted within the list elements.
So maybe you could adapt your formalization in a different way, or just use one of these workarounds:
Rewriting your term into a β-redex:
Definition lC := (fun z o => [z;z;z;o] : list C) 0 1.
Or inserting a few more typecasts around each element:
Definition lC := [0:C; 0:C; 0:C; 1:C].
Regarding your last question
Why does Coq think I want Rs rather than Zs?
this comes from your line Open Scope R_scope., which implies numeral litterals are recognized by default as belonging to R (which deals with the classical axiomatization of the real numbers formalized in the standard library Reals). More specifically, the implementation has changed in Coq 8.7, as from coq/coq#a4a76c2 (discussed in PR coq/coq#415). To sum up, a literal such as 5%R is now parsed as IZR 5, that is, IZR (Zpos (xI (xO xH))), while it used to be parsed to a much less concise term in Coq 8.6:
Rplus R1 (Rmult (Rplus R1 R1) (Rplus R1 R1)).
How could be created a correct state machine (without a way to construct it in invalid way) in Coq entirely from inductive types?
Starting from something like:
Inductive Cmd :=
| Open
| Send
| Close.
Inductive SocketState :=
| Ready
| Opened
| Closed.
For example transition from Ready to Opened should happen only after Open command.
From the formal definition of deterministic finite state machine:
A deterministic finite automaton M is a 5-tuple Q, Sigma, delta, q0, F, consisting of
a finite set of states Q
a finite set of input symbols called the alphabet Sigma
a transition function delta: Q * Sigma -> Q
an initial or start state q0 in Q
a set of accept states F being a subset of Q
You gave two out of the five, namely Q = SocketState and Sigma = Cmd. Assuming that your application has an implicit initial state (probably Ready) and no specific "accept states", the only thing needed for your state machine is the transition function.
From the definition, the transition function has the type (SocketState * Cmd) -> SocketState, but the curried version SocketState -> Cmd -> SocketState is equally powerful.
If your state machine has external inputs, add them as parameters to the function. If you want side effects, or some kind of output associated with the transition itself, you can use SocketState -> Cmd -> (SomeOutput * SocketState).
Edit: Transition as a relation (Extension to keep_learning's answer)
If you want to reason about a series of valid commands and transitions, you might want to encode it into a ternary relation instead.
First, let's define what constitutes for valid transitions.
Previous state -> (Command) -> Next state
-----------------------------------------
Ready -> (Open) -> Opened
Opened -> (Send) -> Opened
Opened -> (Close) -> Closed
Then, encode it as a ternary relation. The following is just an example, similar to Hoare triples from programming language models.
Inductive Transition : SocketState -> Cmd -> SocketState -> Prop :=
| t_open : Transition Ready Open Opened
| t_send : Transition Opened Send Opened
| t_close : Transition Opened Close Closed.
The above talks about a single transition. What about a series of transitions? We can define a reflexive-transitive closure, taking a list of commands (this is very similar to Hoare triples, in the sense that both define a precondition, a sequence of steps, and a postcondition):
From Coq Require Import List.
Import ListNotations.
Inductive TransitionRTC : SocketState -> list Cmd -> SocketState -> Prop :=
| t_rtc_refl : forall s : SocketState, TransitionRTC s [] s
| t_rtc_trans1 : forall s1 c s2 clist s3,
Transition s1 c s2 ->
TransitionRTC s2 clist s3 ->
TransitionRTC s1 (c :: clist) s3.
The function analogue of RTC relation would be (the fold_left in Coq has the last two arguments swapped, compared to Haskell's foldl or Ocaml's fold_left):
Axiom transition : SocketState -> Cmd -> SocketState.
Definition multistep_transition (state0 : SocketState) (clist : list Cmd) :=
fold_left transition clist state0.
You can encode your rules (transition function) into inductive data type.
Inductive Valid_transition : SocketState -> SocketState -> Type :=
| copen x : x = Open -> Valid_transition Ready Opened (* Input command Open *)
| cready x y : x = Send -> Valid_transition y Opened ->
Valid_transition Opened Opened (* Send command would not change the
status of port *)
| cclose x y : x = Close -> Valid_transition y Opened ->
Valid_transition Opened Closed. (* Close command would close it *)
Check (cready Send _ eq_refl (copen Open eq_refl)).
The only way to move from Ready to Opened is first constructor with command Open. The second constructor states that if your command is Send, and you are in Opened state then you would continue to remain in this state. Finally, third constructor closes the open port after receiving Close command. I have encoded a similar transition function as yours (vote counting as state machine), so feel free to have a look at it [1].
[1] https://github.com/mukeshtiwari/EncryptionSchulze/blob/master/code/Workingcode/EncryptionSchulze.v#L718-L740
I'm trying to define an entity named isVector using the following syntax
Require Export Setoid.
Require Export Coq.Reals.Reals.
Require Export ArithRing.
Definition Point := Type.
Record MassPoint:Type:= cons{number : R ; point: Point}.
Variable add_MP : MassPoint -> MassPoint -> MassPoint .
Variable mult_MP : R -> MassPoint -> MassPoint .
Variable orthogonalProjection : Point -> Point -> Point -> Point.
Definition isVector (v:MassPoint):= exists A, B :Point , v= add_MP((−1)A)(1B).
And the Coq IDE keeps complaining that there's a syntax error for the definition. Currently, I haven't figured it out.
There are many problems here.
First, you'd write:
exists A B : Point, …
with no comma between the different variables.
But then, you also have syntax errors on the right-hand side. First, I'm not sure those 1 and -1 operations exist. Second, function calls would be written this way:
add_MP A B
You can write them the way you do:
add_MP(A)(B)
But in the long run you should probably become used to the syntax of function calls being just a whitespace! You might need to axiomatize this -1 operation the way you axiomatized other operations, unless they are a notation that you defined somewhere but did not post here.
Thanks for the help.
After experimenting a little bit. Below is the solution that works.
Definition Point:= Type.
Record massPoint: Type := cons{number: R; point: Point}.
Variable add_MP: massPoint -> massPoint -> massPoint.
Variable mult_MP: R -> massPoint -> massPoint.
Definition tp (p:Point) := cons (-1) p.
Definition isVector(v:massPoint):= exists A B : Point, v = add_MP(cons (-1) A)(cons 1 B).
How can one see the exact implementation of an in-built tactic in Coq ? More specifically is there an alternative to Print Ltac <user-defined-tactics> which works for locating the exact definition of in-built Tactics in Coq ?
No, there is no alternative to Print Ltac. In part, this is because the built-in tactics are implemented in OCaml, and the parts they are made of aren't always expressible in terms of more primitive tactics in Ltac (and almost never would such a translation be exact). The only way I know to find the definitions is to go source-diving. If you search for, e.g., "destruct", you will find in plugins/ltac/g_tactic.ml4 the lines
| IDENT "destruct"; icl = induction_clause_list ->
TacAtom (Loc.tag ~loc:!#loc ## TacInductionDestruct(false,false,icl))
which says that destruct gets parsed as the atomic tactic node TacInductionDestruct. Searching for TacInductionDestruct gives an implementation in plugins/ltac/tacinterp.ml:
(* Derived basic tactics *)
| TacInductionDestruct (isrec,ev,(l,el)) ->
(* spiwack: some unknown part of destruct needs the goal to be
prenormalised. *)
Proofview.Goal.nf_enter begin fun gl ->
let env = Proofview.Goal.env gl in
let sigma = project gl in
let sigma,l =
List.fold_left_map begin fun sigma (c,(ipato,ipats),cls) ->
(* TODO: move sigma as a side-effect *)
(* spiwack: the [*p] variants are for printing *)
let cp = c in
let c = interp_destruction_arg ist gl c in
let ipato = interp_intro_pattern_naming_option ist env sigma ipato in
let ipatsp = ipats in
let sigma,ipats = interp_or_and_intro_pattern_option ist env sigma ipats in
let cls = Option.map (interp_clause ist env sigma) cls in
sigma,((c,(ipato,ipats),cls),(cp,(ipato,ipatsp),cls))
end sigma l
in
let l,lp = List.split l in
let sigma,el =
Option.fold_left_map (interp_open_constr_with_bindings ist env) sigma el in
Tacticals.New.tclTHEN (Proofview.Unsafe.tclEVARS sigma)
(name_atomic ~env
(TacInductionDestruct(isrec,ev,(lp,el)))
(Tactics.induction_destruct isrec ev (l,el)))
end
You can find the implementation of Tactics.induction_destruct in tactics/tactics.ml.
Most primitive tactics start in one of two ways: either there is an entry in g_tactic.ml4 which says how to parse that tactic as an atomic tactic node, or there is a TACTIC EXTEND somewhere, e.g., for revert, we have in plugins/ltac/coretactics.ml4
TACTIC EXTEND revert
[ "revert" ne_hyp_list(hl) ] -> [ Tactics.revert hl ]
END
If the definition is as a node in the Ltac AST, then the place to look is tacinterp.ml, which describes how to interpret those tactics. Either way, you can continue chasing down OCaml definitions to see how tactics are implemented.
Is there a way to Reset (or more generally, free) universes in Coq?
Universe M.
Print Sorted Universes. (*M = Type.2*)
Fail Print M. (*Error: M not a defined object.*)
Reset M.
Print Sorted Universes. (*M = Type.2*)
Definition M := Type#{M}.
Print M. (*M = Type: Type*)
Print Sorted Universes. (*M = Type.2*)
Reset M.
Fail Print M. (*Error: M not a defined object.*)
Print Sorted Universes. (*M = Type.2*)
Whatever I do, M = Type.2. I'm in Coq 8.5
I've found 2 ways. Reset Initial destroys the entire environment (which is usually more than one would want). Another way is to mask universes w/ modules
Universe M R. Constraint M < R.
Definition M := Type#{M}. Definition R := Type#{R}.
Check M:R. Fail Check R:M. (*the hierarchy holds*)
(*1. w/ modules:*)
Module i.
Universe M R. Constraint R < M.
Check M:R. Fail Check R:M. (*still holds*)
Definition M := Type#{M}. Definition R := Type#{R}. (*but now..*)
Fail Check M:R. Check R:M. (*not any more*)
Print Sorted Universes. (*2 Rs and Ms, w/ the old hierarchy masked by the new one*)
End i.
(*outside the module the old hierarchy holds*)
Check M:R. Fail Check R:M.
(*2. w/ Reset Initial:*)
Reset Initial. Fail Check M:R. Fail Check R:M.
Print Sorted Universes. (*the def-d univ-s are gone*)