Closed cocreature closed 8 years ago
I like this idea, thanks.
I think I would prefer if we can minimize the amount of "real code" that is generated (this was my goal with both haskell-xkbcommon and haskell-wayland) - so merely write the pattern synonyms, and leave the current TH-based symbol generation intact.
Is it a sensible idea to put these patterns in a separate module (not re-exported anywhere) as to not congest the namespace?
Effortless building with cabal is a must. So if you can make that work that'd be great - otherwise I can do that bit.
Note that even with pattern matching, there is no guarantee that the list of symbols is in any sense "complete" - so you'll always need an "otherwise" case.
Is it a sensible idea to put these patterns in a separate module (not re-exported anywhere) as to not congest the namespace?
Sounds good to me.
Note that even with pattern matching, there is no guarantee that the list of symbols is in any sense "complete" - so you'll always need an "otherwise" case.
Of course, it's just nice to be able to pattern match on it and then have an otherwise case instead of having to use guards.
I'll give it a shot when I have time, which should hopefully not take too long.
Fixed by a9c84b1
I hope to find time this weekend to release this code.
Take your time it’s not urgent from my side, thanks :)
I had to insert some hacks into Setup.hs to make cabal sdist
stop complaining. But v0.0.2 is online.
It would be nice, to have the stuff in KeysymList available as pattern synonyms. That allows pattern matching on them. This would require 7.8 which seems reasonable at that point.
However right after thinking about that I realized that template haskell does not yet support pattern synonyms. One can work around this by generating an actual file like gl does. I'll leave it up to you to decide if that's worth the trouble. If you are willing to accept that or even like the idea I'll make PR.