-
This issue documents my proposal to extend the PlusCal language with features that enable composability.
Currently one PlusCal algorithm cannot interact with another in any way. They cannot refer t…
-
In other words, the same label name could be reused across processes/procedures (and the PlusCal to TLA+ translator is responsible for making sure labels are unique).
Make sure the atomicity infere…
-
The PlusCal user manual says in section 2.1 that \neq can be used as well as # or \=. However this doesn't seem to work, and it doesn't appear in the table of translations.
(Sorry if this isn't the…
hcs64 updated
5 years ago
-
Consider the following pluscal spec:
```
-------------------------------- MODULE bug --------------------------------
(* --algorithm bug
variables foo = 0 \* missing separator token
fair pr…
-
The `either` statement executes a random non-blocking clause. We could implement this with `select` in Go, but it's difficult to get it into a format where `select` works.
Original issue: https://b…
-
On https://www.learntla.com/pluscal/behaviors/
![image](https://user-images.githubusercontent.com/2660212/32465543-724ac98c-c309-11e7-87c9-0f11d485b397.png)
Does not follow label rules from http…
-
We want to be able to compile a variety of single threaded PlusCal algorithms before moving on to dealing with concurrency. This should involve handling set construction, complicated variable init…
-
This is an issue documenting my ideas regarding translating MPCal archetype parameters into Go.
The general principle I've been operating under is that a parameter would be an instance of an interf…
-
Please explain or give me a way to apply these same concepts to .NET core. I would like to be sure my .NET core code matches exactly my specification and/or just verify my C# code. Thanks.
-
PlusCal may support some TLA+ operations that may not be found in the TLAExprParser token dictionary. If these exist, we need to add them to the dictionary and handle them properly.
Original is…