Add a stock Ord instance for AlexPosn

[Kleidukos]

Close #233

This PR adds an Ord instance to the generated and the internal AlexPosn struct.

[andreasabel]

@Ericson2314 : This change will break compilation of project that add an orphan instance Ord AlexPosn, so I want a second opinion, e.g. what versioning concerns (3.2.8 vs. 3.3).

[andreasabel]

https://hackage-search.serokell.io/?q=instance+Ord+AlexPosn gives the following conflicts:

• https://github.com/TokTok/hs-cimple
• https://github.com/vmchale/jacinda
• https://github.com/vmchale/kempe

[andreasabel]

Resolved the conflict; planning to release this as 3.3.0.

Candidate at: https://hackage.haskell.org/package/alex-3.3.0/candidate

[Kleidukos]

@andreasabel I'm slightly lost wrt the test suite. Despite having changed the wrapper, I don't think the test suite actually failed on the content change of the generated lexer, despite said content having changed in my tree.

❯ grep -R "deriving (Eq, Show, Ord)"
basic_typeclass.n.hs:        deriving (Eq, Show, Ord)
basic_typeclass.g.hs:        deriving (Eq, Show, Ord)
[…]

[andreasabel]

I don't think the test suite actually failed on the content change of the generated lexer,

Maybe you expected a "golden value" test, which does not exist here. The testsuite just generates lexers from .x files, I think it does not even try to run them. The generated lexers are not checked in as golden values.

[Kleidukos]

ooooooh I see! Thank you :)

[andreasabel]

Can't get hold of John @Ericson2314 it seems. Maybe then we just go ahead with the 3.3.0 plan.

[Kleidukos]

@andreasabel understood, I'll merge it then.

[andreasabel]

@andreasabel understood, I'll merge it then.

Maybe the final "hit the button" should be priviledge of the maintainers (stern look). Or do you want to apply for co-maintainership?

[Kleidukos]

My apologies, I was operating under a "take responsibility of your contributions" model.

I am a very poor user of Alex right now, but perhaps after a few other contributions I would certainly consider helping out with maintenance. :)

[andreasabel]

I would have reorganized the commits a bit so that testcase is in the same commit with the change, but so be it now.

perhaps after a few other contributions I would certainly consider helping out with maintenance. :)

Contributions are very welcome!
I think it is also nice if maintainers have sparring partners, so that one can get a second option.

[Ericson2314]

@andreasabel I am very sorry I did not respond to this in time.

[Ericson2314]

Looking at it after the fact, the change and the version number bump seem good to me. The state of the version numbers on Alex and Happy is a little weird, but hopefully we can consistently get back to 4 digit ones so the interpretation of the PVP is most obvious.

[andreasabel]

@Ericson2314

@andreasabel I am very sorry I did not respond to this in time.

No worries!

Looking at it after the fact, the change and the version number bump seem good to me. The state of the version numbers on Alex and Happy is a little weird, but hopefully we can consistently get back to 4 digit ones so the interpretation of the PVP is most obvious.

We can release this as 3.3, 3.3.0, or 3.3.0.0. Technically, this is a strictly increasing version sequence, but non-experts (like my former self) would consider these equal.

Historically, Alex had both x.y (2.2, 2.3, 3.0) and x.y.0 (2.1.0, 3.1.0, 3.2.0) with x.y.0 dominant recently, so I went for 3.3.0. However, we could continue our 4-digit streak and switch to exactly 4 digits always, so 3.3.0.0 would be next.

I take your statement as a vote for 3.3.0.0, @Ericson2314, is this your intention?

[andreasabel]

Release candidate for 3.3.0.0 at:

• https://github.com/haskell/alex/pull/239