Closed Kamirus closed 5 years ago
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?
@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 ;-)
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.
@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.
Also in tests I found that
was broken, because that file does not exist. So I commented out this line and line where it was used.