Does quantification really need to many dependencies?

[edemko]

(Hey lookatthat, I'm doing code things again 0o0 Anyway...)

I just wanted to pull in the Exists type real quick, but instead I also had to wait for the notoriously expensive aeson compile. While it's merely a time-wasting issue, on reflection it seems a little unusual that a type theoretic primitive would require so many dependencies. /understatement I could have just implemented a simple Exists by hand without so much as the prelude!, and it probably would have taken less time than waiting for aeson 🙃

Would you be amenable to splitting out a new quantification-aeson library from quantification? Or even pulling a quantification-core library out that just defines the Exist* types and some instances? Obviously, this will mean creating orphan instances, but the way I see it: that's just what happens when Alice and Bob independently write libraries (the concept of existential quantification, and then aeson), and then Charlie wants to use both of their work meshed together (how quantification currently stands).

[andrewthad]

The aeson thing is annoying and also causes some kind of build plan failure about once a year since aeson keeps tweaking its API. I'd be fine with moving the aeson instances to a separate package as orphan instances. Fortunately, this repository is already structured as a multi-library repo, so if you PR a change adding a quantification-aeson library that exposes a Data.Exists.Aeson module (with orphan instances and all the FromJSONForall stuff), I'd accept that.

Related thoughts:

• This library includes an integration with the binary library (Data.Binary) that has not been useful in ages. That could just be deleted and the dep on binary dropped. Not sure if you care about that dependency though.
• The libraries primitive and hashable are pretty lightweight, and they get pulled into almost any nontrivial projects as transitive dependencies anyway, so I prefer to leave those.

[edemko]

I've gone ahead and pulled out the aeon-related stuff as described (#10). As far as the other thoughts:

• The binary dependency is quite small, even transitively, so I don't think it makes a practical difference. Maybe leave it until the next time it becomes a maintenance chore, y'know?
• I agree with primitive and hashable being fine to keep; especially hashable, which is in so many projects already.
• Actually, now that I look again, it seems that primitive is only a dependency transitively through vector, which is now only a dependency of quantification-aeson anyway.