lobster VS tlaplus

I think lobster does this.

"Compile time reference counting / lifetime analysis / borrow checker."[1]

"Reference Counting with cycle detection at exit, 95% of reference count ops removed at compile time thanks to lifetime analysis."[1]

[1] https://strlen.com/lobster/

There is another language, Lobster, that uses lifetime analysis like Rust, but IIUC infers lifetimes completely automatically. It looks like the idea is still experimental - I'm interested to see how it goes.

I think the ability to open a window and do graphical stuff is actually pretty underrated in core language functionality. There's a few game-oriented programming languages like Lobster that put windowing and graphics in the core language functionality, and I think it's pretty neat. The biggest downside is that it's a lot to bite off, because you'll probably want to have standardized API functionality for a whole host of things like font rendering, image loading, etc.

The actual game itself, yes. Based on this open source project though which provides the language its written in and core engine tech: https://github.com/aardappel/lobster

I'm keeping an eye on Lobster though. It fixes most of Python's problems. It's way faster, has proper static typing, the import system is sane, etc.

Lobster (https://strlen.com/lobster/) appears to at least do lifetime analysis to reduce refcounting. I'm not sure about automatic interior mutability. I feel like there's a keyword here that can help find other compilers with similar features.

Also, can I introduce you to https://strlen.com/lobster/, a garbage collected language made for game development by (and primarily for) the one and only Wouter "aardappel" van Oortmerssen?

I would like to make it work to some degree like Rust with a borrow checker, and have optional static typing (with type inference wherever it can). Other sources of inspiration, lobster lang, and dart. It is going to (eventually...) compile to several places like dart (browser, iOS, android, linux, etc.). After I've created the AST, I've gone straight to code generation, because that's the easy part IME. But now have to insert the "middle" and do typechecking/borrowchecking/inference/other checking. This is for an imperative-style language.

Over the ~12 years of Lobster (https://strlen.com/lobster/) 's existence, features that were removed (in this order): * Lexical scoping. * Icon style backtracking. * Small-talk like syntax. * Dynamic Typing. * Multimethods. * Frame based state (like FRP). * Co-routines.

```

https://github.com/tlaplus/tlaplus/blob/master/tlatools/org....

In any case, our whole team thinks TLA is great, and we're happy people like you and Ron find it so useful and insightful. We also think it is a very insightful.

There are no tests! There are various ways to test concurrent data structures. You could use a stress test, where you spawn a lot of threads and let them mutate the map in a random way and then check the consistency of the map and some invariants. You could learn TLA+ and write a formal model of the map and then verify it.

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

I wish something like Lamport's TLA+ (https://lamport.azurewebsites.net/tla/tla.html) was supported in modern language compilers - perhaps with annotations/macros and a mini formal DSL.

Checking the invariant with assert is also useful in my limited experience with concurrency.

https://lamport.azurewebsites.net/tla/tla.html

One advantage of formal methods is in determining "what was expected" (including all the goofy edge cases) without having to burrow into the details of code.

Take a look at Alloy (http://alloytools.org/) and TLA+ (https://lamport.azurewebsites.net/tla/tla.html) for example. (Or even the ancient Z ("Zed") notation (https://www.cs.cmu.edu/~15819/zedbook.pdf)).

The pcal generator does *not* generate a definition for the set of labels. However, some users have suggested to add such a feature: https://github.com/tlaplus/tlaplus/issues/613