[GHC] #9883: Make OverloadedLists more usable by splitting the class interface

[GHC]

#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