Hey, currently there are a few problems that came ...

# arrow-contributors

[Jannis]

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]

Thoughts/opinions/other ideas?

Back to monorepo 😄

[Jannis]

Nah^^ Splitting arrow-test is a good idea even with a monorepo. It was always such a mess 😅

[raulraja]

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

[simon.vergauwen]

Yes, I agree with you @Jannis! I proposed the same thing yesterday.

[raulraja]

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]

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]

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]

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

[raulraja]

stainless supports @law

[raulraja]

Checks for totality of functions

[raulraja]

Preconditions and postconditions etc.

[raulraja]

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]

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]

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]

When I said Gen I meant our own definition of it.

[Jannis]

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]

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 😅

[Rachel]

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]

@raulraja just saw

https://youtu.be/dkO59PTcNxA▾

. Stainless is very interesting and definitely worth it 😅 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]

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

[Arkadii Ivanov]

@Rachel Is see that arrow-test was archived. Aaaaaandd, my PR (https://github.com/arrow-kt/arrow-test/pull/10) was abandoned, again 😄 How should I proceed with the PR? It blocks my another PR (https://github.com/arrow-kt/arrow-fx/pull/33).

[aballano]

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

[aballano]

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]

Sorry @Arkadii Ivanov, I missed writing a message on those PRs

[Rachel]

Thanks @aballano 🙌

[simon.vergauwen]

Ouch >< 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]

Thanks guys, I will import changes to the arrow-fx PR.

[Rachel]

Thanks @Arkadii Ivanov, sorry for the inconvenience!

[Arkadii Ivanov]

No worries 👍