Hey currently there are a few problems that came up after th

Question

Hey currently there are a few problems that came up after the repo split that concern `arrow test` It being in its own repo means other repos will use a snapshot version of it This means that the changes we are testing are not present in the compiled code of `arrow test` As an example I have a pr that changes the signature of a method in `Applicative` in `arrow core` In `arrow test` we have in `TraverseLaws` a law which uses `Id applicative` and `IO applicative` which both come from the snapshot of `arrow core` This means they don t have the changes and this leads to `AbstractMethodError` s at runtime This was partially solved by < Rachel> with a short term workaround already by recompiling `arrow test` with a current version of the current repo before testing For this pr this meant that the tests using `Id applicative` worked fine but `IO applicative` still failed because it came from `arrow fx` and that is not being recompiled it does not even have the required changes There are probably other compile issues similar to this which are less discover able and harder to debug Any change in a core repo that changes a datatypes representation it s equality instance or any method signature covered by laws has to first change `arrow test` otherwise it will never pass a test This is a significant hindrance for changes as it leads to lots of fractured prs In my opinion the best way out of this is to split `arrow test` for each repo such that `arrow core` has `arrow test core` etc Then force `arrow test core` to only depend on local projects or other `arrow test ` This would mean that changes to for example `arrow core` that would otherwise need to go to `arrow test` are now local It still means we need to create follow up prs in the other repos but solves the issues with the laws Splitting this up is also a fast process which can be done incrementally Create a new module per repo copy all laws generators and eq instances for this repo and last make all local tests depend on it This technically should mean no test has to change although some laws may have to change like `TraverseLaws` Unrelated to this I d also propose to rename `arrow test` to something like `arrow laws` as it really only contains laws generators and equality instances not actual tests Thoughts opinions other ideas

pakoito · Answer

gt Thoughts opinions other ideas Back to monorepo smile

Jannis · Answer

Nah^^ Splitting `arrow test` is a good idea even with a monorepo It was always such a mess sweat smile

raulraja · Answer

I agree Janis also ideally all laws are part of the typeclasses to get closer to how meta can discover them

simon.vergauwen · Answer

Yes I agree with you < Jannis> I proposed the same thing yesterday

raulraja · Answer

Meta may be able to verify laws at compile time if the user provides a Gen for a data type in a extension proof that can be resolved as a constant expression

raulraja · Answer

The IDE would tell the user in real time of the structure of it s type as provided by the Gen instance follows the law It would also allow users to encode tests and predicates alongside their declarations and optionally allowing then to eliminate the laws and gen instances at runtime

Jannis · Answer

That would be running a property test at compile time right This is only better if the test is super fast and thus gives direct feedback which would be amazing^^ Other than that I don t see the benefit over having normal tests

raulraja · Answer

The benefit is that as it evolves as something like Scala stainless we can add a means of formal verification of properties

raulraja · Answer

stainless supports law

raulraja · Answer

Checks for totality of functions

raulraja · Answer

Preconditions and postconditions etc

raulraja · Answer

Make the language safer and bring stronger static analysis Laws are a piece of all that if we recognize type classes as first class citizens

raulraja · Answer

As for how fast the test is it should be pretty fast as in now provided the Gen sample uses simple constant evaluable values such as Id 1

raulraja · Answer

Also the laws can be used in the IDE to highlight or not compile unsafe calls over types that do not abide the constrains the typeclass imposes as laws

raulraja · Answer

When I said Gen I meant our own definition of it

Jannis · Answer

Well I am definitely interested^^ For the current problems I ll prepare a pr for `arrow core` where we can discuss this approach further because this really needs to be solved asap because it will be blocking for some pull requests

Jannis · Answer

Just figured out that `arrow core data` for some reason has a dependency on all of arrow through `arrow docs` which comes from `arrow ank` This makes my initial plan of copying the source and just deleting changing everything that fails to compile impossible for now because you can actually do `fx` and `mtl` etc in `arrow core`^^ I ll add the pr when this is fixed already wrote rachel because I have no idea how that even happens sweat smile

Rachel · Answer

`arrow test` and `arrow docs` are the two hot points `arrow docs` should be re organized as well It was split and it doesn t contain the site However it still has source code that is used for code snippets from the apidocs and it can be split as well for every library

Jannis · Answer

< raulraja> just saw Stainless is very interesting and definitely worth it sweat smile generating equivalence classes from code and checking them is a great concept at least that is my impression of how it works haven t checked the source

Rachel · Answer

There is already a solution for `arrow test` and `arrow docs` It will be improved during next days

Arkadii Ivanov · Answer

< Rachel> Is see that `arrow test` was archived Aaaaaandd my PR was abandoned again smile How should I proceed with the PR It blocks my another PR

aballano · Answer

< Arkadii Ivanov> yes we had to adapt the repo as previously the tests were splitted as you see

aballano · Answer

so now arrow fx contains its own tests so no need to split tests and code in multiple PRs you just need to import your changes to the new arrow fx tests module and continue your PR in arrow fx

Rachel · Answer

Sorry < Arkadii Ivanov> I missed writing a message on those PRs

Rachel · Answer

Thanks < aballano> raised hands

simon.vergauwen · Answer

Ouch gt lt sorry for the inconvenience < Arkadii Ivanov> We can continue the discussion there I cannot answer in the PR since the repo is archived

Arkadii Ivanov · Answer

Thanks guys I will import changes to the `arrow fx` PR

Rachel · Answer

Thanks < Arkadii Ivanov> sorry for the inconvenience

Arkadii Ivanov · Answer

No worries +1