Benjamin

I think I'm misunderstanding myself here. We can have different solutions to sending and recieving data due to the fact that there's never a case (that I recall) that we...

I think one thing that might be useful is using JSON's Alternative instance. This could help with the weirdness seen in 155 with the type integers.

I can see what the issue is, it's exactly as described; when sending a presence update, we need it to be an object of a label and a string, but...

The issue with that in my eyes is that it doesn't ensure what type you'll get on either the receiving end or what you can send; a library user should...

While I think this is a good step in the right direction, I have to point out an issue that I fear may soon stem from this. As Teo points...

Here's the original monoid proposal as far as I can see: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/semigroup-monoid It has similarly not moved in quite some time.

My intent was not to completely take over this proposal, for which I apologise. I recommend you express these sorts of thoughts over in my monad of no return amendment...

So would ``` instance ... => Monoid (Generically a) where mempty = ... -- no mappend ``` be sufficient to get rid of this issue? Would derived instances use the...

I think that's just a misuse of the deriving generically stuff; unless your type encodes the invariants you want, you can't expect the compiler to just guess what instance you...

didn't mean to request review just yet. this builds locally on 9.8.2. removed upper bounds on testing and benchmark deps as suggested by a colleague