nested tuple with one element: Tuple a Unit

[Kamirus]

Also in tests I found that

import Test.Example (run) as Example

was broken, because that file does not exist. So I commented out this line and line where it was used.

[akheron]

The problem is that litps needs to be run before running tests to generate Test.Example from the example in README.md. Everything works if you have litps installed and run the tests by npm test, but currently litps is not installable because https://github.com/Thimoteus/literate-purescript doesn't compile on PureScript 0.12.

@paluh Would it be the easiest solution for now to commit the compiled litps script into this repository?

[paluh]

@Kamirus, Sorry for the delay. I want to merge this together with @akheron PR (which is under review) so I can also update README and make a release. I'm still struggling if this whole nested Tuple approach should be so liberal and inconsistent but probably a bit more pleasant for the end user. I've introduced this inconsistencies alone so these are rather questions to you Guys:

• We can agree that Row* is separate approache to nested tuple and they should not rather be mixed up or.. should they? Do we want to allow mixes like Tuple a Row0?

• Nested tuples representation allows us to represent the same rows in multiple ways. Starting with Tuple a (Tuple b Unit) ~ Tuple a b and ending with nested tuples like Tuple (Tuple a b) (Tuple c d) ~ Tuple a (Tuple b (Tuple c (Tuple d))). Should we keep this liberal approach?

Regarding litps I hope I will test purescrit-literate in a couple of days so we can avoid including external tools in this lib. In general the whole ecosystem (including our other libs :-P) should benefit uf such a tool just works ;-)

[Kamirus]

IMO Tuple (Tuple a b) (Tuple c d) should be isomorphic to Row3 (Tuple a b) c d

I'd say the most consistent way of supporting nested tuples is to treat them as heterogeneous lists (Tuple x xs). So considering Data.Tuple.Nested such nested tuples should end with Unit. But maybe Unit should be optional, since it's not a problem to implement and it's useful to the end user.

[paluh]

@Kamirus

I'd say the most consistent way of supporting nested tuples is to treat them as heterogeneous lists (Tuple x xs).

I think that we should stick to this rule with the single exception for Tuple a b. It should be Tupe a (Tuple b Unit) of course but we can leave this other representation for our user convenience without big harm I think. The other cases like freely nested tuples are probably not so common and only mess up clarity. I think I'm going to drop them in the next release I think.