[Chart] data-accessor, lens, and Chart

[Greg Horn]

Hello,

I would only make two separate packages if you plan on updating both
of them in parallel. I personally don't have any desire for a version
of Chart with data-accessor to be maintained, so I vote for major
version bump.

Greg

On Fri, Mar 22, 2013 at 5:50 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
>
>     tl;dr: I like lens and ported Chart to use it for the following reasons,
>
>      * data-accessor has an annoying namespace conflict with stateref
>      * lens provides more functionality and is therefore more worth my time learning
>      * lens provides (IMHO) better error messages
>      * lens is more likely to enjoy better long-term support
>      * lens doesn't require an odd composition operator
>      * I already use lens in my code
>
>     do others think this is a worthwhile change in Chart (after perhaps a
>     major version bump) or should this constitute a new package?
>
>
>
> I'll admit, I've never really felt comfortable with data-accessor.
>
> Certainly, it's a fine package and has played an important role in the
> evolution of lens-like constructs in Haskell. That being said, it has
> never really gained enough mindshare to be worth learning and using
> myself. This may be in part due to the fact that it is a fairly quirky
> piece of code. It shares a namespace with a module from stateref (a
> fairly consistent point of friction), requires unfamiliar composition
> operators, and features just enough functionality to make it useful yet
> too few to be compelling for one-off use. This is compounded by its less
> than stellar error messages and further by the unhelpful type signatures
> produced by its TH-generated accessors (e.g. accessors are identified by
> the type T).
>
> Recently, I've began playing around with lens. In contrast to
> data-accessor, to me lens feels worth using. Far more than a data
> accessor library, it can encode concepts I previously struggled
> to express. For this reason, lens use has slowly crept in to my everyday
> code (although I still only use a fraction of its namespace). The fact
> that it provides nice data accessors is almost a secondary concern.
>
> Recently I've wondered how much effort would be required to port Chart
> to lens. Needing an mechanical project to wake up to, I gave it a try[1]
> this morning. Perhaps unsurprisingly, the changes were all quite
> straightforward (almost entirely accomplished with regular expressions
> shuffling around underscores). User code was even easier to port,
> requiring in most cases s/^:/./ and s/^=/.~/
>
> I would be happy to see these changes make their way upstream. That
> being said, lens is heavier dependency than data-accessor which may
> scare some away (although it seems pretty likely that lens will become
> ubiquitous before long). Given the nature of the change, it would be
> best if it were accompanied by a major version bump.
>
> What do others think?
>
> Cheers,
>
> - Ben
>
>
>  [1] https://github.com/bgamari/haskell-chart/tree/lens
>
> _______________________________________________
> Chart mailing list
> Chart at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/chart