[Haskell-cafe] Split the IsList class for OverloadedLists

Li-yao Xia lysxia at gmail.com
Fri Oct 30 13:48:10 UTC 2020

Hello Café,

Right now the IsList class used by the OverloadedLists extension 
requires both fromList, to construct something using list syntax, and 
toList, to pattern-match on something using list syntax.

So types implementing that class are expected to be isomorphic to lists. 
This is a very strong restriction. In particular, this gets in the way 
of implementing IsList for aeson's Value type[1], since there's no 
sensible total implementation of toList.

[1]: That is a recently proposed idea 

Proposal: split toList and fromList in two separate classes.

(And modify the OverloadedLists extension accordingly.)

Since they rely on an associated type family Item, it would be made a 
standalone family.

type family Item (l :: Type) :: Type

class ToList l where
   toList :: l -> [Item l]

class FromList l where
   fromList :: [Item l] -> l
   fromListN :: Int -> [Item l] -> l

(Note: we can't just replace ToList with Foldable, because these classes 
have different kinds.)

- Any objections? An obvious concern is backwards compatibility. Is that 
a deal breaker? Are there other issues with this idea?

- Should that be a GHC proposal[2]?

- Has this been discussed before?

[2]: https://github.com/ghc-proposals/ghc-proposals

One alternative is to use RebindableSyntax, which already allows users 
to redefine toList and fromList however they want. The issue is it might 
also mess with all other kinds of syntactic sugar just enough that the 
unpleasantness is not worth the trouble.

For example, if you wanted to use multiple list-like types in one 
module, you would want an overloaded version of fromList/fromListN. You 
either roll your own or find a suitable dependency. Either way it's 
overhead you might not be willing to pay for, as opposed to something 
that's already in base and Just Works.

So even with some existing workarounds in mind, the above proposal seems 
a net improvement over the status quo.

Maybe some day we'll also get to take fromInteger out of Num.


More information about the Haskell-Cafe mailing list