I'm -1 on this. For an abstract DList-style list builder, there's the dlist package, which you shouldn't fear depending on (its only dependencies are base and deepseq, both of which are GHC boot packages). The dlist package defines a DList that's an instance of MonadPlus, Traversable, IsList, Ord, Read, Show, IsString, Monoid, and NFData, and provides a variety of functions for working with them. Many of the instances and functions are, inherently, absurdly inefficient. This is because there's basically *nothing* you can do to a DList directly except build one up with `.` and tear one down with `apply`. DLists are extremely efficient precisely when GHC is able to optimize them away altogether. As soon as that is not the case, they're mediocre at best. Now suppose you want a non-abstract DList type (with the constructor exposed). newtype DList a = DL { unDL :: [a] -> [a] } What can that offer in the way of instances? Well, it's clearly not a Functor, so it's certainly not Applicative, Monad, MonadPlus, or Traversable. Ouch. There's no way to write matching Read and Show instances, so you're stuck picking just one. Similarly, IsList and IsString aren't guaranteed to round-trip properly. NFData is utterly absurd, of course. So what's left? Foldable, Monoid, and either Read or Show. The Foldable instance doesn't even interact nicely with the Monoid instance: there's no guarantee that foldMap f xs <> foldMap f ys = foldMap f (xs <> ys). So there's pretty much *nothing going on here*. DList x just doesn't have much more to offer than Endo [x]. We already have Endo; ergo, we don't need DList. On Mon, Jun 5, 2017 at 3:58 AM, Dr.Koster <drkoster@qq.com> wrote:
Currently GHC already defined DList for internal use in serveral places. This data type is a nature choice when you need CPS your append, which is a common need. I think base should provide it.
Cheers~ Winter
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries