Add unit tests for Tuple

[j-panasiuk]

Simplest tests you will ever see! :)

[j-panasiuk]

In the spirit of https://github.com/elm-lang/core/pull/784/files - for completeness and better coverage statistics :)

[j-panasiuk]

In the spirit of https://github.com/elm-lang/core/pull/784/files - for completeness and better coverage statistics :)

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[jvoigtlaender]

Fun fact: All your four tests are "free theorems". It is impossible to implement first, second etc. with the types they have but not fulfilling these properties. In that sense, these tests do not test anything that the type system has not already guaranteed. That makes the situation different than for the referenced Maybe tests.

[jvoigtlaender]

Fun fact: All your four tests are "free theorems". It is impossible to implement first, second etc. with the types they have but not fulfilling these properties. In that sense, these tests do not test anything that the type system has not already guaranteed. That makes the situation different than for the referenced Maybe tests.

[j-panasiuk]

That's very interesting! So if I wanted to learn more about how Elm's type system works under the hood, where should I look? In this example it makes sense, once pointed out, but these are functions with very straightforward signatures. Is this something you just recognize having enough experience in typed functional language?

I'm currently probing around core to get familiar with how all these basic things are implemented.
I see that, for example, there are only 3 (seemingly randomly chosen) tests for Set: https://github.com/elm-lang/core/blob/master/tests/Test/Set.elm
Would adding tests for remaining functions be a more useful contribution?

[j-panasiuk]

That's very interesting! So if I wanted to learn more about how Elm's type system works under the hood, where should I look? In this example it makes sense, once pointed out, but these are functions with very straightforward signatures. Is this something you just recognize having enough experience in typed functional language?

I'm currently probing around core to get familiar with how all these basic things are implemented.
I see that, for example, there are only 3 (seemingly randomly chosen) tests for Set: https://github.com/elm-lang/core/blob/master/tests/Test/Set.elm
Would adding tests for remaining functions be a more useful contribution?

[jvoigtlaender]

For more discussion of the Elm type system etc., the GitHub issue tracker here is not the right place. You could try the mailing list. (http://elm-lang.org/community)

But in brief, about this:

In this example it makes sense, once pointed out, but these are functions with very straightforward signatures. Is this something you just recognize having enough experience in typed functional language?

There is a precise formal apparatus (relational parametricity) to arrive at such "statements from types". The colloquial term is "free theorems". That approach was first described in the paper "Theorems for free" by Phil Wadler. Should be easy to find online. To play around / generate such statements, you can use http://www-ps.iai.uni-bonn.de/ft. It says "Haskell", but applies to "Elm" as well.

About this:

I see that, for example, there are only 3 (seemingly randomly chosen) tests for Set: https://github.com/elm-lang/core/blob/master/tests/Test/Set.elm
Would adding tests for remaining functions be a more useful contribution?

It's not even said that Evan wouldn't want to merge your tests for Tuple, so I'm not closing the issue here. In general, if you are looking for opportunities to contribute, there are threads on that on the mailing list. A general trend seems to be that Evan is not very keen on code contributions to the Elm repositories. You may want to watch his "Code is the Easy Part" talk on YouTube.

[jvoigtlaender]

For more discussion of the Elm type system etc., the GitHub issue tracker here is not the right place. You could try the mailing list. (http://elm-lang.org/community)

But in brief, about this:

In this example it makes sense, once pointed out, but these are functions with very straightforward signatures. Is this something you just recognize having enough experience in typed functional language?

There is a precise formal apparatus (relational parametricity) to arrive at such "statements from types". The colloquial term is "free theorems". That approach was first described in the paper "Theorems for free" by Phil Wadler. Should be easy to find online. To play around / generate such statements, you can use http://www-ps.iai.uni-bonn.de/ft. It says "Haskell", but applies to "Elm" as well.

About this:

I see that, for example, there are only 3 (seemingly randomly chosen) tests for Set: https://github.com/elm-lang/core/blob/master/tests/Test/Set.elm
Would adding tests for remaining functions be a more useful contribution?

It's not even said that Evan wouldn't want to merge your tests for Tuple, so I'm not closing the issue here. In general, if you are looking for opportunities to contribute, there are threads on that on the mailing list. A general trend seems to be that Evan is not very keen on code contributions to the Elm repositories. You may want to watch his "Code is the Easy Part" talk on YouTube.

[j-panasiuk]

Thanks for taking the time to answer my type related question!

I've watched the talk you mentioned before, so I know Evan's stance on "when do we merge my code??" attitude ;) Still, writing (or rewriting) code is a different beast than writing tests for code that already exists. I see this as a low hanging fruit that doesn't affect things outside of the thing being tested, doesn't introduce complexity, new tradeoffs etc. and so can be picked without bothering Evan or the community at large.

In the worst case PR gets rejected or just floats around indefinitely, and I'm fine with that. For now I'm just looking around for easy things to improve

[j-panasiuk]

Thanks for taking the time to answer my type related question!

I've watched the talk you mentioned before, so I know Evan's stance on "when do we merge my code??" attitude ;) Still, writing (or rewriting) code is a different beast than writing tests for code that already exists. I see this as a low hanging fruit that doesn't affect things outside of the thing being tested, doesn't introduce complexity, new tradeoffs etc. and so can be picked without bothering Evan or the community at large.

In the worst case PR gets rejected or just floats around indefinitely, and I'm fine with that. For now I'm just looking around for easy things to improve

[rtfeldman]

These still seem like worthwhile tests. One thing I learned when working on elm-css is that having even trivial tests which reference things you assume ought to work can expose bugs - for example, functions that type-check but which you forget to expose. (Whoops!)

[rtfeldman]

These still seem like worthwhile tests. One thing I learned when working on elm-css is that having even trivial tests which reference things you assume ought to work can expose bugs - for example, functions that type-check but which you forget to expose. (Whoops!)

[rtfeldman]

Thanks @j-panasiuk!

[rtfeldman]

Thanks @j-panasiuk!