Update all dependency versions. Use PSC 0.10.

[chexxor]

A bug appeared when running tests after upgrading - a Tuple (String Unit) will render with an extra space on the end. I don't know how to fix, and I don't know if this test failed before upgrade. Shouldn't hurt to keep this behavior, though.

[garyb]

Thanks!

Looks like the space is new, but it doesn't seem like a problem to me 😄

[chexxor]

@garyb I discovered why that space was added. It appears this change in purescript-tuples did it: https://github.com/purescript/purescript-tuples/pull/23/files

It adds a Unit to the end of a tuple7. Can you or @natefaubion explain why Unit was forced into the position of the last element of a nested tuple?

[garyb]

Ah right, the tupleN stuff has been changed to be "extensible", meaning the operators like at2 now work regardless of the "length" of the nested tuple - previously there were varieties like get2of3, get2of4, etc. which made working with nested tuples a pain if you needed to grow or shrink them. The cost is that now the last item in a nested tuple is always Unit, similar to the need for Nil at the end of a List.

[chexxor]

So, if I want to make Tuple an instance of a type class, I need to also make Unit an instance of my type class? It seems a bit weird. @garyb, if you think it's right, then I can accept it.

I'm trying to think about how to write a special case to handle the last element of a nested tuple. Can we pattern-match to know we're at the end and can handle that special-case? There's no data constructor for Unit, so I believe we can't. I believe this is the difference between List and nested Tuple - List has Cons and Nil constructors, but Tuple only has Tuple constructor.

[garyb]

Another way of looking at it, is the T3 type now means "At least 3", it's Tuple a (Tuple b (Tuple c ...))

[garyb]

Oops, didn't see your message before I posted that ^.

This is purely due to a use of a Tuple.Nested representation somewhere, if it was just using Tuples "normally" the extra Unit would be unnecessary, but also the nested combinators would not work. The Tuple.Nested stuff is just synonyms: https://github.com/purescript/purescript-tuples/blob/master/src/Data/Tuple/Nested.purs#L33-L42

So no, the instances for Tuple don't have to involve Unit or anything, it's still just represented as data a b = Tuple a b.

[chexxor]

That's a very helpful way of looking at it, thanks.

I feel this CSS library should move away from Data.Tuple.Nested's "tupleN" functions. I'm looking at usages here and we're taking advantage of extensible tuples. Instead, should we manually create these Tuples to ensure they don't end in Unit? Or move away from Tuples and use List instead?

[garyb]

I think creating them manually would be better than using a List, since at least they have fixed arity this way... but I'm not sure if that matters in the way things are currently represented anyway. I think there's plenty of improvements this library could potentially have!