iq_res_title should be required (not Maybe)

[klappvisor]

iq_res_title should be required (not Maybe)

[klappvisor]

@fizruk Unfortunatelly there is an optional title in the other constructors, so it's done this way as common denominator

[klappvisor]

@fizruk But if you can suggest better option, I would be happy to implement it

[fizruk]

@klappvisor I'm currently experimenting with Telegram Bot API using this library. This was the first thing I noticed. However it is a very minor thing.

Recently I noticed that Telegram Bot API simulates sum types:

At most one of the optional parameters can be present in any given update.

This object represents one button of an inline keyboard. You must use exactly one of the optional fields.

Exactly one of the fields data or game_short_name will be present.

telegram-api currently copies data type design and does not leverage sum types for these objects.
And it makes handling updates somewhat painful (without pattern synonyms or lenses) and also allows for invalid data to be constructed (which could be avoided easily with sum types).

In any case, I'm still trying things out and I may have more concrete suggestions later :)

[klappvisor]

@fizruk Thank you for your feedback! It's actually very relevant, you are right, but it would require major breaking change. I guess it's better to do it anyway, hopefully together with the others I could find, to avoid constantly breaking API.

As user, what do you think about current order of the arguments in runClient?
Currently:

runClient queries token manager

Or

runClient token manager queries

That will make it possible to write

runClient toekn manager $ do
  me<- getMeM
  webhook <- getWebhookInfoM

Any other suggestions are welcome