dlist in the Haskell Platform? (was 2013.4.0.0 proposal)

[Sean Leather]

I think it might be better to continue the dlist discussion on a separate
thread. For a recap, see below.

As I've just taken over maintenance and development of dlist (and nobody
seems to be complaining, yet, so I guess I'll just continue with it), I've
looked through the code and thought about things a bit. Here are my
thoughts.

(1) The original proposal was for aeson to be in the platform. As Bas
pointed out, dlist is not a crucial dependency. It is certainly a
convenience, but he would be willing to remove it if the consensus called
for it.

(2) Some people would prefer to have dlist in the platform on its own
merits, not as a (minor) dependency for another library.

(3) dlist has been stable for many years. Another way of looking at it is
that dlist has remain unchanged for that amount of time.

(3a) I had to do a bit of work to get the tests compiling and running again.

(3b) There are a number of type class instances that would make dlist more
useful. Bas proposed some. I implemented others [1].

(3c) The DList type really should be abstract [2]. This is a primary reason
for using `DList a` over `[a] -> [a]`: to guarantee the isomorphism with
lists.

(4) I plan to make the above changes and release a new major version. But
considering the nearness of the HP release, I expect some people would
hesitate before introducing a newly updated library into a presumably
stable collection such as the HP. The resulting options would be (a) adding
the current version (0.5) or (b) not adding it at all.

The concept of dlists has been around for years, and it's a well-known way
for dealing with a particular problem. The library implementation and
design is sound. People use it [3]. For these reasons, I think it makes
sense for the platform.

But at the moment, to avoid unnecessary controversy and to give the new
code some time to mature, I recommend that dlist is *not* added to the
platform.

Regards,
Sean

[1] As an aside, I think the assumption that conversion between dlists and
lists impacts performance in a significant way is not well-founded. dlists
remove left-nested appends, and I don't see how they can increase runtime
by more than a linear factor on the length of the lists. Nonetheless, I
would like to have/see benchmarks before coming to a conclusion on the
matter.

[2] https://github.com/spl/dlist/issues/4

[3] http://packdeps.haskellers.com/reverse/dlist

----------
> From: *Mark Lentczner* <mark.lentczner at gmail.com>
> Date: Sun, Nov 10, 2013 at 11:40 PM
> Including aeson, which I think we'd all very much like to do, requires
> dlist-0.5.
> Now, dlist has been around for a very long time, and is very stable.
> I do not believe that dlist's API is exposed indirectly via aeson at all.
> I hereby propose that it be added to the platform.
> At the very least, it could be like primitive - in the platform, but not
> "part" of it.
> ----------
> From: *Johan Tibell* <johan.tibell at gmail.com>
> Date: Sun, Nov 10, 2013 at 11:41 PM
> Fine by me.
> ----------
> From: *Dag Odenhall* <dag.odenhall at gmail.com>
> Date: Mon, Nov 11, 2013 at 6:19 PM
> Wouldn’t it be trivial to get rid of the dlist dependency using Endoinstead, too? It seems to only be an implementation detail. On the other
> hand, maybe dlist in Platform makes sense anyway.
> ----------
> From: *John Lato* <jwlato at gmail.com>
> Date: Mon, Nov 11, 2013 at 6:30 PM
> This is true, and in fact I almost never use dlist myself (or Endo), since
> lambdas are already quite light weight.
> However, dlist makes the intention explicit, which is probably a good
> enough reason to use it in a package in the platform.
> ----------
> From: *Bas van Dijk* <v.dijk.bas at gmail.com>
> Date: Tue, Nov 12, 2013 at 10:26 AM
> +1
> However, note that I don't mind dropping the dlist dependency from
> aeson. I use it in a very limited internal place:
> https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Generic.hs#L213
> Don, If we do decide to include dlist in the HP it would be great if
> the following instances can be added to it:
> instance Alternative DList where
>     empty = empty
>     (<|>) = append
> instance Eq a => Eq (DList a) where
>     (==) = (==) `on` toList
> instance Ord a => Ord (DList a) where
>     compare = compare `on` toList
> instance Show a => Show (DList a) where
>     showsPrec p dl = showParen (p >= 10) $
>                      showString "Data.DList.fromList " . shows (toList dl)
> ----------
> From: *Sean Leather* <sean.leather at gmail.com>
> Date: Tue, Nov 12, 2013 at 12:47 PM
>
> Considering the somewhat fundamental nature of dlist, I think it would be
> appropriate to have in the platform.
> Assuming Don is willing and others agree, I don't mind taking over
> maintenance of dlist. I just imported it into GitHub:
> https://github.com/spl/dlist
> Bas: please submit a pull request with the suggested changes. They all
> look good.
> ----------
> From: *Bas van Dijk* <v.dijk.bas at gmail.com>
> Date: Tue, Nov 12, 2013 at 2:52 PM
> Done: https://github.com/spl/dlist/pull/1
> ----------
> From: *Joachim Breitner* <mail at joachim-breitner.de>
> Date: Wed, Nov 13, 2013 at 7:53 PM
> while dlist is certainly a nice and stable library, it is still
> relatively specialized, and I would personally not consider it important
> enough to be included in the platform. I’d like the platform to stay a
> selection of packages that people not only can use, but really should
> know about, and use them instead of rolling their own. I’m not sure if
> this holds for dlist – using [a] -> [a] and (.) directly is also good
> practice.
> My suggestion is to remove it from aeson, and keep the platform small
> and focused.
> ----------
> From: *Bas van Dijk* <v.dijk.bas at gmail.com>
> Date: Wed, Nov 13, 2013 at 8:10 PM
> I would call using [a] -> [a] and (.): "rolling your own" and I consider
> it bad practise. Code would be easier to understand if it used common names.
> I think its best if I remove dlist from aeson and that we discuss its
> inclusion into the HP (after next) in a separate proposal.
> Sean: care to lead the proposal?
> ----------
> From: *Bardur Arantsson* <spam at scientician.net>
> Date: Wed, Nov 13, 2013 at 8:17 PM
> +1.
> It's not so much that dlist is "bad" or anything, but it's more that
> dependencies (of any kind) have a non-trivial cost considering that that
> Haskell modules are currently IMD and not SMD. (See the very interesting
> paper here: http://plv.mpi-sws.org/backpack/index.html).
> ----------
> From: *Joachim Breitner* <mail at joachim-breitner.de>
> Date: Wed, Nov 13, 2013 at 8:20 PM
> I’m not sure; there is a concept behind it that applied to other data
> types as well, e.g. trees, possibly defined by the user. Having people
> knowledgeable about [a] -> [a] will enable them to apply the same
> pattern to their own data types.
> If [a] -> [a] were bad practice, then base should stop using it¹, and
> Data.DList should become part of base. (This is not a strawman argument:
> If people support this then sure, why not).
> One main advantage of dlist if of course that it comes with instances
> (Monad, Functor, etc.)
> ¹
> http://hackage.haskell.org/package/base-4.6.0.1/docs/Prelude.html#t:ShowS
> ----------
> From: *Mark Lentczner* <mark.lentczner at gmail.com>
> Date: Wed, Nov 13, 2013 at 9:48 PM
> The platform hasn't been aiming for "small and focused" for quite some
> time. And last year I called for a significant expansion of the palatform,
> and this was met with general enthusiasm. The original motto for the
> platform: "batteries included" is still apt.
> We want to the platform to provide, out-of-the-box, a broad selection of
> packages for common computing needs, where these packages can be counted on
> to be there, to be stable, and be a reasonable default choice - and hence
> worth learning and keeping in your toolbox. Not every package has to be
> "the only best way" to do some task - Python includes a default HTTP
> server, but there are plenty of others out there, and good reasons to
> choose them. We want packages to be the reasonable default to turn to, when
> the choice doesn't warrant researching through alternative packages on
> hackage, or soliciting opinions on IRC.
> Of course, the transitive nature of packages in the platform means that
> sometime we have things in there that don't quite live up to those goals.
> primitive is in the platform because vector needs it... but it isn't quite
> a common computing need.
> Dlist probably wouldn't have made it in on it's own merits - but it isn't
> bad, and certainly a reasonable way to do what it does if that is what you
> need and just want to get on with whatever else your doing. (perhaps our
> motto should be "less yak-shaving"!) Since the use of Dlist isn't exposed
> in aeson's interface , it could go either way. But I think it would be
> reasonable to include.
> ----------
> From: *Stephen Tetley* <stephen.tetley at gmail.com>
> Date: Thu, Nov 14, 2013 at 12:34 AM
> On 13 November 2013 18:20, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > One main advantage of dlist if of course that it comes with instances
> > (Monad, Functor, etc.)
> I consider these instances a disadvantage of DList as you have to
> metamorph via a List to use them.
> As this isn't germane to the debate, though,  I'll crawl back under my
> stone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20131114/e223ca7a/attachment.htm>