daig/intrinsic-superclasses

A quasiquoter implementation of Intrinsic Superclasses proposal

intrinsic-superclasses's Issues

Handle associated type and data instances

Currently we only handle function and value definitions in instances.

Currently blocked as https://github.com/bmillwood/haskell-src-meta/ can't parse associated types

Handle `Forall` constraints

If we have a class like

class ForallF Functor p => RFunctor p where rmap :: (a -> b) -> p x a -> p x b

we want to detect Functor as a superclass of RFunctor and define the appropriate instances

There's some consideration about how to nicely handle a general solution, but simply special-casing ForallF will get a lot of benefit

Add default methods

-XDefaultSignatures is of limited use for a rich typeclass heirarchy as it cannot handle multiple defaults. To improve encapsulation, default methods should morally live at the subclass declaration site, not in the superclass.

There are a few design possibilities here - I'm leaning towards scraping all methods in scope of the form default_Foo_bar to give default definition for bar when deriving [instances| Foo ... |]

Regression Tests

Due to the messiness of TH, it would be helpful to have tests to prevent breaking edge cases when adding new features or refactoring.

generate an error for incomplete instances

Incomplete instances are much easier to accidentally generate when deriving a whole hierarchy, so it should generate a compile error from within the TH splice

disambiguate defaults by class

Defining multiple defaults for the same method will clobber eachother, even if they utilize different sublcass methods. This leads to a nasty nonlocal bug where an upstream module may fail to compile if it is imported together with a module that clobbers the default it wants, even though locally that upstream module imports the right defaults.

Add an extra Name argument to defaulting which takes the name of the subclass providing the default, and disambiguate using it in instances

Find an alternative to `haskell-src-meta`

Right now we use haskell-src-meta for the quasiquote parser because template-haskell's [d|...|] quoter rejects additional methods in instance declarations that actually belong to the superclasses.

We'd like to move away from haskell-src-meta because it is not synced with GHC proper, and in particular is blocking a number of issues (#2 , #3)

Handle empty classes

Currently classes without methods will simply be ignored - we'd like to simply generate empty instances for them.

The obvious implementation is blocked on #4

Improve compilation performance

I haven't run into issues yet in practice, but the implementation is naive and likely very slow at scale. Due to the general slowness of TH this can be a big usability improvement.

Also a good opportunity to clean up the code which is kind of a mess right now.

On hold until problems manifest in the wild. Pipe up if it bugs you or have benchmarks!

Handle infix method definitions

Currently infix operators must be instantiated in head position (like (<>) a b = a + b) or value position (like (<>) = (+)), but we should be able to handle the natural definition a <> b = a + b.

Blocked upstream on bmillwood/haskell-src-meta#66
The issue has been fixed but needs to be pushed as a new version to hackage

Weaken superclass requirements

currently if we write

[instances | Foo f => Bar (Baz f) where ...|]

then all the methods will have the required context Foo f, even if that particular superclass does not require Foo, making our instances hold in less places than they should. This is remedied by manually adding a superclass instances with the correct context before instances, but in the worst case every superclass has a weaker context than the subclass so instances is useless.

We'd like to automatically weaken the context for each superclass based on the actual constraints on the default methods. This is likely to be tricky and possibly require implementing type inference.

Only generate instances when not already in scope

If a superclass instance is already in scope, we want to use that instance rather than trying to generate a new one. Currently attempting to derive instances already in scope will give a duplicate-instance compile error.

Without this it is impossible to use this library to extend base classes.

Handle Multiparam typeclasses

Currently we only support traditional typeclasses

Better Examples

CommutativeGroup is not very inspiring as it does not actually add any laws. Think of an example that is both useful and informative.

It may be worth combining examples with Regression Tests (#11)

Only generate instances once

Currently if we have a diamond of superclasses like

class Monoid a => CommutativeMonoid a
class Monoid a => IdempotentMonoid a
class (CommutativeMonoid a, IdempotentMonoid a) => TrivialMonoid a

Then attempting to derive TrivialMonoid Foo will generate duplicate instance declarations for Monoid Foo.

This can be fixed by a careful implementation of #4 but can also be fixed independently