On Jan 9, 2007, at 9:12 PM, Spencer Janssen wrote:
On Jan 9, 2007, at 7:52 PM, Marc Weber wrote:
Hello.
Is here the right place to request a list class? eg class List l e where (:) :: e -> l e -> l e head :: ..
Note that this approach isn't quite flexible enough. Your example forces the container type to have kind * -> *, and therefore can't support certain specialized containers like ByteString.
There is a class like this in the Edison library (http:// www.eecs.tufts.edu/~rdocki01/edison.html), it is called Seq (Haddocks: http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data- Edison-Seq.html). However, it suffers the same kind flexibility issues as your List class. Other classes in Edison take a MPTC +fundep approach and I'm not sure why Seq doesn't. Can you comment on this, Rob?
I consider this mostly a historical artifact. The Edison design dates back to about 1998, before fundeps were available in a Haskell implementation. The Set/Bag and Finite Map classes were designed with MPTC, but no fundeps. The sequence class was nicer because it was more elegant, and played nicer with type inference. In the course of time, Set/Bag and Finite Map classes got fundeps, and became a bit nicer. When I took over maintenance, the typeclass hierarchy was much as it is now. I am personally in favor of the idea of changing the sequence class to the MPTC+fundep approach, for largely the reasons you've mentioned. The downsides are twofold: 1) Functor, Monad, and MonadPlus could no longer be superclasses of Sequence and 2) its a pretty major API change. Despite the downsides, I've become convinced this is the right direction to go, and this change will almost certainly take place sometime in the not too distant future. I'm now finished with some work which was occupying most my attention for the last six months or so. I am also considering a more sweeping API reorganization, where the typeclasses become less monolithic (especially the sequence class), and the non-observable classes go away, but I'm still trying to figure out the most optimal way to restructure things, so this change won't happen for awhile.
This might be used in Data.Set, Data.Map
class StorableAsList l e t where fromList :: l e -> t toList :: t -> l e
This is subsumed by other Edison functionality.
I'd like to help implementing/ writing it.
Do you consider this beeing a useful enhancement?
Oh yes, but let's avoid reinventing the wheel if at all possible.
Spencer Janssen
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG