エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao

エンジニア目線で見る
TLA⁺ と PlusCal
LINE Blockchain Lab
TAKAMI Torao
2021-04

考えてたこと
分散システムや⾮同期
処理のテストは超絶ハー
ドすぎ!💀
01
設計が「正しいこと」を⾦
融システムでも通⽤する
⽅法で証明するには?
02
AWS や FF-XV のテス
トに使ってる
TLA⁺[1,2,3] ってなんだ?
03

理想的な世界
形式⼿法︓並⾏システムの正しさ (構
造上起き得ないこと) を証明
⼀般的なテストフレームワーク︓個々
の単⼀プロセスがうまく動くこと確認
Safety
Liveness
Load & Save
Validation Search

ボイラープレートと変換
サンプルを読むのに必要な最低限の知識

TLA+ か PlusCal か?
Check
時相論理式に似せた構⽂
TLA⁺
(1999)
Transpile
⼀般的なプログラミング⾔語に似せ
た構⽂
PlusCal
(2005)
---- MODULE HelloWorld ----
EXTENDS TLC
(* --algorithm HelloWorld
begin
Greeting:
print "hello, world";
end algorithm; *)
====
EXTENDS TLC
VARIABLES pc
Init == pc = "greeting”
Greeting == /¥ pc = "greeting"
/¥ PrintT("hello, world")
/¥ pc' = "finish”
Termination == /¥ pc = "finish”
/¥ UNCHANGED pc
Next == Greeting ¥/ Termination
====
TLC
⼀般的なプログラミングの設計には
ボイラープレート多すぎ 🙁
📌 If you see the ¥ (yen) symbol on these pages, all mean ∖ (backslash).
📌

TLA⁺ と PlusCal の共存
1. PlusCal のモデルは TLA⁺ のブロックコメ
ント部分に記述する。
2. EXTENDS は import や use に似てい
る。右の例は print を使うために TLC を
EXTENDS している。
3. Step または Action とはラベルのついた
1 つ以上の⽂の集まり。
4. PlusCal トランスレータはコメント部分に
TLA⁺ 表現を挿⼊しモデルファイルを作
る。
EXTENDS TLC
begin
Greeting:
end algorithm; *)
====
TLA⁺ 構⽂
ブロックコメント
T4
bacteriophage
HelloWorld.tla
EXTENDS TLC
begin
Greeting:
end algorithm; *)
¥* BEGIN TRANSLATION (chksum(pcal) = "8124a86e" /¥ chksum(tla) = "56880286")
VARIABLE pc
vars == << pc >>
Init == /¥ pc = "Greeting"
Greeting == /¥ pc = "Greeting"
/¥ PrintT("hello, world")
/¥ pc' = "Done"
(* Allow infinite stuttering to prevent deadlock on termination. *)
Terminating == pc = "Done" /¥ UNCHANGED vars
Next == Greeting
¥/ Terminating
Spec == Init /¥ [][Next]_vars
Termination == <>(pc = "Done")
¥* END TRANSLATION
====
😅
SPECIFICATION Spec
¥* Add statements after this line.
HelloWorld.tla
HelloWorld.cfg

証明のアプローチ
TLA+ はどうやって正しさを保証するのか?

そもそも「正しさ」ってなんね?
並⾏システムにおいて、正しさ (correctness) とは Safety と
Liveness[4] である。
ü Safety
なにか悪いことが決して起きないこと
Ø 例. ⾃動⾞⽤信号と歩⾏者⽤信号は同時に⻘にならない。絶対にだ!
ü Liveness
いつか良いことが起きること
Ø 例. 歩⾏者はいつか横断歩道を渡ることができる。

時相論理
assert(x >= y); // present state
⼀般的なプログラミング⾔語向けのテストフレー
ムワークの assert は「今そうであること」しか表
現していない。
時相論理は時制上の論理学で過去、現在、未来を表現することができる
• Globally: □ 𝑥 ≥ 𝑦; すべてのステップで満たされる
e.g., ∀𝑎 ∈ 口座: □𝑎. 残高 ≥ 0,
𝑝, 𝑐 ∈ 青, 赤 : □¬(𝑝 = 青 ∧ 𝑐 = 青)
• Eventually: ◇ 𝑥 ≥ 𝑦 ; 将来のどこかのステップで満たされる
e.g., ∃𝑛 ∈ 𝑁𝑜𝑑𝑒𝑠: ◇𝑛. 𝑣𝑜𝑡𝑒𝑠 >
"
#
𝑁𝑜𝑑𝑒𝑠. 𝑠𝑖𝑧𝑒
• Led to: 𝑥 ≥ 𝑦 ↝ 𝑥 ≥ 𝑧 ; 𝑥 ≥ 𝑧 は 𝑥 ≥ 𝑦 が満たされた後にいつか
満たされる。つまり 𝑥 ≥ 𝑦 ⇒ ◇𝑥 ≥ 𝑧 と同じ。
• Or else.
𝑥 ≥ 𝑦 𝑥 ≥ 𝑦 𝑥 ≥ 𝑦 𝑥 ≥ 𝑦 𝑥 ≥ 𝑦
𝑥 ≥ 𝑦 𝑥 ≥ 𝑦 𝑥 ≥ 𝑦 𝑥 < 𝑦 𝑥 ≥ 𝑦
Success
Failure
𝑥 < 𝑦 𝑥 < 𝑦 𝑥 < 𝑦 𝑥 ≥ 𝑦 𝑥 < 𝑦
𝑥 < 𝑦 𝑥 < 𝑦 𝑥 < 𝑦 𝑥 < 𝑦 𝑥 < 𝑦
Success
Failure
制約としての「決して」や「いつか」を
どう表現すればいいのか?
そこで時相論理ですよ。

TLA⁺ はどうやって safety と
liveness 特性を保証してい
るのか?
TLC モデルチェッカーは:
1. モデル (TLA⁺で書かれた仕様) を有限状態機械とみな
す。
2. モデルをステップ単位で実⾏してゆく。
3. システムの取りうる状態、ステップ進⾏具合、⾮決
定的動作のすべての組み合わせを再現して状態
を探索する。
4. すべてのステップまたは経路で、すべての時相論理
制約、アサーション、終了 (termination) などの条
件が満たされていることを確認する。
雑に⾔うと、TLC は内部的に UML で⾔うところのステートダイ
アグラムを構築してる。
---- MODULE Steps ----
EXTENDS Integers, TLC
(* --algorithm steps
variables s = [i ¥in
1..2 |-> 0];
process P ¥in 1..2
begin
Step1:
s[self] := 1;
print s;
Step2:
s[self] := 2;
print s;
end process;
end algorithm; *)
====
A B
C
D
E
F
G
H
I
J
Z
Model (TLA⁺) 状態遷移
Safety に対して
• Globally の時相特性を確認する。これは到達可能なすべての状態
で満たされていなければならない。
• ライブロック (または閉路) の検出する。
Liveness に対して
• Eventually な時相特性を確認する。これは経路上のどこかの状態
で満たされていなければならない (終了条件を含む)。
• 発⽣しないイベントを無限に待ち続けるデッドロックを検出する。
状態遷移図は制御フロー図のことではないよ

状態遷移を探索する
TLC はどうやってすべての状態を再現するのか?

PlusCal の構⽂は単体テストのコードによ
く似ているが、制御フロー上の分岐やルー
プをテストしているわけではない。
どうやって
「すべての可能な状態」を
再現しているのか?
---- MODULE States ----
(* --algorithm States
variables
x ¥in 1..3,
y ¥in 1..2;
begin
Step1:
x := x % 2;
y := y % 2;
Step2:
assert x >= 0 /¥ y >= 0;
print << x, y >>;
end algorithm; *)
====
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(0,0)
(0,1)
(1,0)
(1,1)
Init
Step1 Step2
(𝑥, 𝑦)
(0,0)
(0,1)
(1,0)
(1,1)
Terminating
ステップで発⽣した状態数 (上の図の四⾓)
ステップ上で実⾏されたアクション数 (つまり上の図の⽮印)
▶Result
このシステムの状態
変数
ステップ; TLC が 1
処理サイクルで実⾏
する単位

どうやって
「すべての処理の進⾏状況」を
---- MODULE Steps ----
(* --algorithm steps
variables s = [i ¥in 1..2 |-> 0];
process P ¥in 1..2
begin
Step1:
s[self] := 1;
print s;
Step2:
s[self] := 2;
print s;
end process;
end algorithm; *)
====
(1,0)
(0,1)
Init
(0,0) (2,2)
Terminating
𝑠 (1,1)
(2,1)
(1,2)
(2,0)
(0,2)
Step1
Step1
Step2
Step2
Step1
Step1
Step1
Step1
Step2
Step2
Step2
Step2
Process 1
Process 2
▶Result
プロセス 𝑖 の現在の状態を 𝑠! としたとき、システムの状態変数を 𝑠 = (𝑠", 𝑠#) とすると:
• Step1×6 (橙⽮印) と Step2×6 (⻘⽮印) のアクションが存在する。
• Step1 も Step2 も 3 種の状態を⽣成し (StepN とラベル付けされた⽮印の先にある四⾓の種
類)、そのうち 2 つは Step1 からも Step2 からも⽣成される。
各プロセスの進⾏を状態変数化することで
PlusCal はプロセスの進⾏具合の組み合わ
せも検査する。これによりレースコンディショ
ンの検出が可能になる。
TLA⁺ にトランスパイルしたとき、上記 𝑠 と同じ⽬的の pc と
いう変数が⾃動で⽣成される。
2つのプロセスを起動

either と with はユーザ⼊⼒や外部システム
のレスポンスのような⾮決定的動作を記述する
ために使う構⽂。
---- MODULE ReadPassword ----
(* --algorithm ReadPassword
variables try = 0, input = "";
begin
ReadPassword:
while input /= "success!" /¥ try < 3 do
either input := "success!";
or input := "failure?";
end either;
try := try + 1;
end while;
Finally:
assert input = "success!" ¥/ try = 3;
print << try, input >>
end algorithm; *)
====
(1,”success!”)
(0,””)
(1,”failure?”)
(2,”success!”)
(2,”failure?”)
(3,”success!”)
(3,”failure?”)
例えば正しいパスワードが⼊⼒されるまで最⼤ 3 回の認証を試⾏ができるシ
ステム↓
either 𝐴;
or 𝐵;
or ⋯
end either;
with 𝑥 ∈ {𝐴, 𝐵, ⋯ } do
⋯
end with;
(try,input)
これにより、⼆重署名や改ざんなどのビザンチン
的な⾏動を表現することが可能になります。
どうやって
「⾮決定的動作」を
Init

TLC は状態遷移のすべての経路を探索した時点で
停⽌します。したがってシステムが終了しないことが⾃
明であっても探索は停⽌します。
---- MODULE InfiniteLoop ----
EXTENDS TLC
(* --algorithm InfiniteLoop
variables flag = FALSE;
begin
Loop:
while TRUE do
flag := ~flag;
end while;
end algorithm; *)
====
探索の終了
flag=FALSE となった 3 回⽬以降の Loop ステップはすで
に検査済みなので実⾏する必要がない。
FALSE
flag
Init
TRUE
Loop
Loop

Safety と Liveness 特性の検証
実際のコードを使って「正しさ」を確かめる

---- MODULE Crosswalk ----
(* --algorithm Crosswalk
variables signal = << "green", "red" >>,
define
DontGreenAtTheSameTime == [](~(signal[1] = "green" /¥ signal[2] = "green"))
Flip(s) == IF s = "green" THEN "red" ELSE "green"
end define;
begin
Switch:
while TRUE do
S1: signal[1] := Flip(signal[1]);
S2: signal[2] := Flip(signal[2]);
end while;
end algorithm; *)
====
どうやって Safety 特性を
検証すればよいか?
時相論理演算⼦ [] を使って Globally 制約を定
義し、モデルファイルの PROPERTIES でそれを指定
します。
この例では 2 つの信号機が同時に⻘になることはな
いと想定しているが、実際は事故が起きるケースが
存在します。
SPECIFICATION Spec
PROPERTIES DontGreenAtTheSameTime
signal
Init
S1 S2 S1
Invariant
NoAccidents is
violated.
Safety には時相論理式だけではなく通常
のアサーションも使うことができる。

実際の Safety 指定⽅法
• Globally 時相特性を使う⽅法
1. モデル内で [] 付きの時相特性を定義します。
NoOverdrafts == ∀𝑎 ∈ 𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠: □𝑎. 𝑏𝑎𝑙𝑎𝑛𝑐𝑒 ≥ 0
2. それらをモデルファイル内の PROPERTIES に指定します。
PROPERTIES NoOverdrafts
• Invariants を使う⽅法
1. Invariant でなければならないルールを定義します。
PMustBePrime == 𝑝 > 1 ∧ ¬(∃𝑥 ∈ 2, . . , 𝑝 − 1 : 𝑝 % 𝑥 = 0)
2. それらをモデルファイル内の INVARIANTS に指定します。
INVARIANTS PMustBePrime
• アサーションを使う⽅法
assert x + y > 0
通常は “globally” 時相特性とアドホックなア
サーションを使います。
Invariants も globally 要件に使えなくはな
いが、本来の意味は型制約の代⽤らしい。
ASSUME はモデルファイルで外部定義された
定数が想定したものかのチェックに使う。

Liveness の考え⽅はやや難しく、検証に
も⼤量の計算が必要。
どうやって Liveness 特性を
検証すればよいか?
スタッタリング
• スタッタリング (stuttering) とは、実⾏可能なステップがあるにもかかわらずど
のステップも実⾏されない処理サイクルのこと。
• 有限回数のスタッタリングであれば証明に影響しないが、TLA⁺では無限回
のスタッタリングが起きることを許可している。
• 並⾏システムに於いて、無限回のスタッタリングとはプロセスの Crash-Stop
障害を意味している。
• TLA⁺ では、デフォルトで任意のプロセスが任意のステップで無限回のスタッ
タリングを起こす。
公平性
• fair 付きの process (または algorithm やステップ) はこの無限回のスタッ
タリングを回避し、いつか実⾏されることが保証されます。
• つまり、fair 付きプロセスは決して Crash-Stop しないことを暗に意味しま
す。
• マルチプロセス環境では、await による有効化と無効化を繰り返すプロセス
を進⾏するために強い公平性 fair+ が必要なることがある。
Livenessプロパティを説明する前に、TLA⁺
には理解しておくべき 2 つの重要な概念があ
ります。

どうやって Liveness 特性を
検証すればよいのか?
時相論理演算⼦ <> を使って制約を定義し、
モデルファイルの PROPERTIES に指定します。
この例では、⻘と⾚に切り替わる歩⾏者⽤信
号と、⻘になったときに道路を渡ることのできる
歩⾏者からなるシステムを⽰している。
では信号が⻘にならなかったり、プロセスに fair
がついていない場合は何が起きるか?
道路を横断しようとしている歩⾏者と歩⾏者⽤信号機の連携システム
---- MODULE Crosswalk ----
(* --algorithm Crosswalk
variables signal ¥in {"green", "red"},
went_through = FALSE;
define
PedestrianHasCrossed == <>went_through
Flip(s) == IF s = "green" THEN "red" ELSE "green"
end define;
fair+ process Pedestrian = "pedestrian"
begin
Wait:
await signal = "green";
WentThrough:
went_through := TRUE;
end process;
fair process Signal = "signal"
begin
Switch:
while TRUE do
signal := Flip(signal);
end while;
end process;
end algorithm; *)
====
SPECIFICATION Spec
PROPERTIES PedestrianHasCrossed

Liveness 特性に違反してみると
Q3. Pedestrian を弱い公平性に変えると何が起きる?
¥* fair+ process Pedestrian = "pedestrian"
fair process Pedestrian = "pedestrian"
A3. 信号が⻘になった途端に歩⾏者がスタッタリングす
ることを延々と繰り返して歩⾏者が永遠に道路を
渡ることがでない可能性があります。
¥* fair process Signal = "signal"
process Signal = "signal"
A2. 信号機が⾚になった状態でクラッシュ停⽌ (無限
のスタッタリング) を起こした場合、歩⾏者は永遠
に道路を渡ることができません。
Q2. Signal から fair を消すと何が起きる?
Q1. もし信号が⼀度も⻘にならなかったら?
¥* Flip(s) == IF s = "green" THEN "red" ELSE "green"
Flip(s) == "red"
A1. 道路を横断することなく状態グラフの探索が終了するため検
証に失敗します。

どうやって Termination を検証
するのか?
-termination オプションはシステムの狩猟を検査
する簡易的な⽅法です。この Termination 特性
は以下のように書くこともできます。
PlusCal options (-termination)
---- MODULE InfiniteLoop ----
EXTENDS TLC
(* --fair algorithm InfiniteLoop
variables flag = FALSE;
begin
Loop:
while TRUE do
flag := ~flag;
end while;
Finish:
print "finish"
end algorithm; *)
====
抽象化されたシステム設計ではシステム全体の termination は必須というわけではない。Termination の代わりに独⾃の
終了条件を時相特性として定義し使⽤することができる。
SPECIFICATION Spec
PROPERTY Termination
𝑇𝑒𝑟𝑚𝑖𝑛𝑎𝑡𝑖𝑜𝑛 ≝ ◇(∀𝑠𝑒𝑙𝑓 ∈ 𝑃𝑟𝑜𝑐𝑆𝑒𝑡: 𝑝𝑐 𝑠𝑒𝑙𝑓 = "Done")
この場合、たった 1 つのプロセスでも無限回のスタッタリングを起こすと制約
違反となるため、すべてのプロセスは fair 特性を保つ必要があります。

実際の Liveness 指定⽅法
• Eventually 時相特性を使う⽅法
1. <> 時相演算⼦を持つ制約を定義する。
TransferCompleteness == ◇∀𝑎 ∈
𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠: □𝑎. 𝑏𝑎𝑙𝑎𝑛𝑐𝑒 ≥ 0
2. モデルファイルの PROPERTIES にそれらを指定する。
PROPERTIES NoOverdrafts
• –termination オプションを使う⽅法
1. 以下のいずれかで指定
1. ソースファイル内の PlusCal options (-
termination)
2. コマンドラインから -termination
2. アルゴリズム全体やすべてのプロセスに fair を付ける。
--fair algorithm …
単にシステムの終了を確認したい場合は -
termination オプションを使う⽅法が簡単。

TLA⁺ は計算量爆発が
起きやすいのでは?
計算量爆発を起こすのは超簡単
アクション数と状態数は:
• 各状態変数の定義域
• マルチプロセスにおけるステップの実⾏順
序
• ⾮決定的なケース
の組み合わせです。
TLA⁺ では抽象化が最も重要で難しい作業
[5]です。
variables
PublicKey ∈ {1,…,0xFFFFFFFFFFFFFFFF},
Signature ∈ {1,…,0xFFFFFFFFFFFFFFFF};
begin
Step1: if Verify(PublicKey, Signature) then …;
2"#
×2"#
の組み合わせ
ケースが発⽣する
現実的な値ではなく、抽象的な意味に対して検査する
either
(* if the specified signature is valid *) …
or
(* or not *) …
end either;
しかし 2$%
×2$%
個の状態が個別に異なる意味を持つことはないですよ
ね? もし本当にこのようなテストが必要であれば単体テストとしてテスト
フレームワークで⾏うべき。
“valid” とは何を意味するのか、また実装時に検証し
なければならないことを明らかにする必要があります。
抽象化は主観的な作業です。この場合「証明されている」というのはどの程
度信⽤できるでしょうか?
Liveness テストは特に計算量が多く、多くの場合 Safety 検査とは
別により単純なモデルで⾏わなければならないようです。

まとめ
• TLA⁺ と PlusCal はシステム仕様を検査し、有限状態機械 (有限オートマトン) の観点から
状態遷移を探索します。ここで状態とは各プロセスの進⾏状況も意味します。
• TLA⁺ は抽象化された並⾏システムに於いて時相論理演算⼦を使⽤してそれぞれの状態の
Safety と Liveness を検証します。
• 抽象化は最も重要ですが困難な作業です。⾮常に主観的な作業なので「証明済み」を盲
信せず、何が採⽤され何が省略されたかをよくレビューする必要があります。

References
1. Use of Formal Methods at Amazon Web Services
https://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf
2. How Amazon Web Services Uses Formal Methods
https://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext
3. FINAL FANTASY XV POCKET EDITION を⽀える AWS サーバレス技術
https://d1.awsstatic.com/events/jp/2018/summit/tokyo/customer/37.pdf
4. Proving the Correctness of Multiprocess Programs (1977) L. Lamport
https://ieeexplore.ieee.org/document/1702415
5. The TLA+ Video Course (2020) L. Lamport
http://lamport.azurewebsites.net/video/videos.html (recommended to watch first)
6. PlusCal / TLA⁺: An Annotated Cheat Sheet (2019) S.Merz
https://d3s.mff.cuni.cz/f/teaching/nswi101/pluscal.pdf
7. Summary of TLA⁺
https://lamport.azurewebsites.net/tla/summary-standalone.pdf

定理証明
形式仕様
その他の形式⼿法 (おおむね正しくはない認識)
⾃動定理証明
(E, SPASS, Otter, etc.)
対話型証明システム
(Coq, Alloy, F*, Agda, Isabelle, etc.)
抽象的
論理学的
数学的
与えられた論理式 𝐴, 𝐵, … , 𝑍 か
ら経路探索的に 𝐴 から 𝑍 への
証明経路を探すシステム。
仕様記述⾔語
(TLA⁺, VDM, Z, etc.)
具体的
実装寄り
⼯学的
コード化された論理構造
に不整合や脱落がない
ことを検証するシステム。
テスト
実装
エンジニアリング

Visual Studio Code を使った
TLA⁺ と PlusCal の実⾏
1. Visual Studio Code をインストールして TLA+ 拡張を追加する。
2. Module.tla ファイルに検証したい処理を記述する。ファイル名がモジュール名 ---- MODULE Module
---- と⼀致していることを確認。
3. PlusCal の場合は [View]-[Command Palette...] メニューを選択するか [CTRL]+[Shift]+[P] を押
して “TLA+: Parse module” を選択してトランスパイルを実⾏する。このとき TLA⁺ コードが挿⼊され
module.cfg ファイルが⽣成される。
4. ファイルを右クリックして “Check model with TLC” で TLC を実⾏する。
5. 地獄への⾨が開く。

逐次処理を記述するための構⽂
if 𝑃 then 𝐴;
elsif 𝐵;
elsif ⋯
else ⋯
end if;
Label:
while 𝑃 do
𝐴;
end while;
goto Label;
IF 𝑃 THEN 𝐴;
ELSE 𝐵;
END IF;
CASE 𝑃 -> 𝐴;
[] 𝑄 -> 𝐵;
[] 𝑅 -> 𝐶;
OTHER -> 𝐷;
PlusCal はオブジェクト指向や関数型のパラダイ
ムのように複雑な操作を簡単に書くための⾔語
機能を持っていない。
その理由はおそらく、それらが有限状態機械の
状態遷移を複雑にするためだと思われる。
構⽂; “else if” に相当
する機能はない
構⽂
式
TLA⁺ 構⽂ PlusCal 構⽂
”for” は⽤意されていない
これだけ?? 😇
See also: [6][7] for other language features.

マルチプロセス
メッセージング
• 状態変数はプロセス間のメッセージングにも使われま
す。
• ある条件が真となるまでステップを実⾏対象外とする
wait という機能があります。
variables greeting = "";
process A = "A"
begin
WaitMessage:
await greeting /= "";
Print:
print greeting;
end process
process B = "B"
begin
Say:
greeting = "hello, world";
end process

Operators and Notations
TLA⁺ Notations Math
Expressions
Meanings
x := y Assign the value of 𝑦 to 𝑥.
x == 10 ≜ Define 𝑥 as 10.
x ¥in {A,B,C} 𝑥 ∈ {𝐴, 𝐵, 𝐶} Let 𝑥 be an element of the set {𝐴, 𝐵, 𝐶}.
x ¥in 1..9 𝑥 ∈ {1, … , 9} Let 𝑥 be an element of the set {1, … , 9}.
P /¥ Q 𝑃 ∧ 𝑄 Logical disjunction of 𝑃 and 𝑄.
P ¥/ Q 𝑃 ∨ 𝑄 Logical conjunction of 𝑃 and 𝑄.
~P ¬𝑃 Negation of 𝑃.
x = y 𝑥 = 𝑦 𝑥 equals to 𝑦.
x /= y 𝑥 ≠ 𝑦 𝑥 doesn’t equal to 𝑦.
P ¥equiv Q 𝑃 ≡ 𝑄 𝑃 equivalents to 𝑄.
¥A x ¥in S: P(x) ∀𝑥 ∈ 𝑆: 𝑃(𝑥) For all elements 𝑥 in the set 𝑆, 𝑃(𝑥) is satisfied.
¥E x ¥in S: P(x) ∃𝑥 ∈ 𝑆: 𝑃(𝑥) There exists an element x in the set S that satisfies P(x).
+,-,*,/,% Arithmetic operators
x ¥o y 𝑥 ∘ 𝑦 Concatenate the tuples or strings.
CHOOSE x ¥in S: P(x) Select arbitrarily element 𝑥 from the set 𝑆 that satisfies 𝑃(𝑥).
TLA⁺ Nots. Meanings
"abc" String literal.
<<A,B,C>> Tuple or list (𝐴, 𝐵, 𝐶)
[a|->1,b|->2] Struct {a:1, b:2}
[i ¥in 1..3|->i*i] Tuple (1, 4, 9)
ToString(number)
Len(tuple)
See also: [6][7] for other language features.

エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao

Recommended

Recommended

More Related Content

Similar to エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao

Similar to エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao (20)

Recently uploaded

Recently uploaded (10)

エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao