#9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: normal | Version: 7.8.3 Component: External | Keywords: overloaded lists, Core | islist Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: 7495 None/Unknown | Related Tickets: #7495 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by muesli4): Replying to [comment:3 simonpj]:
I'm far from sure that it's a dup of #7495, so I'm reopening. This ticket has a clear proposal; #7495 does not. I'm not sure either. I was trying to get a discussion running about this, since I'm not that much experienced in Haskell (at least I haven't written an extension), which does not mean I'm not interested in working on GHC. :)
By all means go ahead and forge a consensus about this ticket.
I wonder if `IsList` could be a superclass of `AsList`? It could and it would even remove the redundant element type definition. My first intent was, to decouple the ''literal''-functionality from the rest. That's also a point I don't like about the {{{Num}}} class, instead of using {{{Num}}}, one could provide the ''literal''-functionality with a {{{NumLit}}} class, which then in turn could be a super class of {{{Num}}}. But I'm not sure whether I'm keeping track of everything it affects, so feel free to correct me.
That is, do you want to be able to pattern-match on a list-like thing, but not be able to use literals for that type? It could make sense, though I admit probably not often.
Or are they best considered as orthogonal? Aren't they already orthogonal semantically in the OverloadedLists extension?
I would keep them split, if someone needs both, he or she can use both.
The nomenclature clearly needs fixing!
How about this (I added the {{{ListView}}} class only because I thought it sounded exactly how it should be.): {{{ {-# LANGUAGE TypeFamilies #-} type family ListViewItem :: * -> * -- From ListLiteral class ListLit l where fromList :: [ListViewItem l] -> l fromListN :: Int -> [ListViewItem l] -> l -- From ListConvertible class ListConv l where -- Name could conflict with Data.Foldable.toList toList :: l -> [ListViewItem l] -- From ListViewable, since we provide a view into something utilizing a list. -- FIXME Better use some kind of type class alias here! class (ListLit l, ListConv l) => ListView l where }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9883#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler