In an ideal world, there would be no coupling to the Prelude library and the library itself would implement (through something like template PureScript) the auto-derivation. Although that requires a ton of machinery that does not yet exist, and plenty of people want Eq/Ord now, so 👍

True. Another option is to bake things like Eq and Ord into Prim and put the code gen into the constraint solver. But that's kinda gross.

Ok, this is ready to review.

Presumably it still works when you want to derive an instance which has a field that itself derives the instance? Perhaps the tests should cover that too? Not sure.

Also, does this work for records, like newtype X = X { foo :: Int, bar :: String }? If so, I guess the test should include a record too?

Good points @hdgarrood, thanks. It should work in both cases. I'll modify the tests.

Actually, the problem with Ord on records is that the labels are unordered, so lexicographical ordering doesn't make sense. So perhaps we should disallow those cases?

I guess the point is that we're just picking some ordering for records, not that there is a canonical one, but since most Ord instances will just be used to put things into maps and sets, I think that's okay.

Good to review again.

Re Ord and records: yeah, that's what I was about to say. 👍

Actually, the problem with Ord on records is that the labels are unordered, so lexicographical ordering doesn't make sense. So perhaps we should disallow those cases?

Well, on sum types, the order is the declared "text" order of the terms in the sum. It'd be nice if the order for fields were the declared "text" order.

@jdegoes Yes, it is.

👍

@jdegoes @hdgarrood Another option is to use the ordering given by taking labels in alphabetical order. Thoughts on this before this goes into 0.8.1?

I think I'd expect the ordering to be given by the order labels were written, although if I really cared about it, I'd probably just write the Ord instance out explicitly. So, no particularly strong feelings either way.

Another option is to use the ordering given by taking labels in alphabetical order.

Very strongly opposed to this on the following grounds:

1. It's inconsistent with derived Ord for sum types, in which the ordering is the declared order. Observation: users know this and will arrange their constructors to obtain a desired ordering (e.g. data DoW = Sunday | Monday | Tuesday ...).
2. It's inconsistent with derived Ord for the "other" product type (data), in which the ordering is the declared order. Observation: users know this and will arrange their constructors to obtain a desired ordering (e.g. data OrderDetails = OrderDetails OrderId ....
3. If a user is looking at a derived Ord for a record, what will they predict the ordering will be? They could randomly guess "alphabetic ascending", "alphabetic descending", or some such, but given both (1) and (2), and given the user has already declared an ordering of the fields (declaration order), I believe very strongly most users will predict declared order. If we want to totally surprise users and make their predictions wrong, then we need to have a very good reason for doing so.
4. Finally, a weak argument but still a valid one: the whole point of deriving is to save users work. It makes sense to maximize the number of cases for which the derivation is useful. If you choose any arbitrary ordering not under control over the user, you will, by definition, decrease the number of cases in which derivation is useful, causing users to do more work than necessary. A user who wants alphabetical ordering can always choose to obtain that ordering by alphabetizing their fields; but a user who wants a custom ordering in the alphabetical scheme will be forced to write the Ord instance manually.