Corinna VS tlaplus

this the repository of initial draft:https://github.com/Ovid/Cor

after they proposed this, people debating around this in long time.

Have you been following the developments with Perl's forthcoming OOP engine, Corinna?

You can read about some of the discussions here (that's after the BUILD/BUILDARGS debate). Unfortunately, since much of the discussion took place on IRC, and there's a policy against allowing public logging without explicit permission of the channel owners (I am not an IRC guy, so I'm not one of the channel owners), much of this valuable discussion has been lost to time. I don't wish to repeat this mistake in future projects, but I can't change the past.

I've opened a discussion about revisiting Twigils.

However, I wouldn't shelve your plans to put more time into Moose. The PR for the initial Corinna work is out and while /u/leonerduk's work is great, the PR is huge and there are a few minor issues to deal with. I do not know when the initial Corinna work will be finished and even after that, it will be a couple of years before it's considered "stable."

From the Rationale for Corinna:

It's based on years of experience being the lead designer of the Corinna project and trying to figure out how we can get a version of Moose which is safer and easier to use, including removing a lot of boilerplate. This code:

By now most of you have probably heard about the Corinna project to get modern object-oriented programming in the Perl core. The RFC has been submitted to P5P and it's a slimmed down version of the full specification. It's in seven stages, each building on the last.

Then you'll be happy to know that I've submitted an RFC to the core Perl team to introduce a modern OO model to the language. So far the response has been positive and we already have /u/leonerduk who's committed himself to implement it.

```

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