[Chart] data-accessor, lens, and Chart

[Tim Docker]

(Looks like the github migration may be paying off already)

I've had the same feelings about data-accessor, but have not yet used 
lens. So I'm broadly in favour of this idea, but I'd like a little time 
to get comfortable with lens, or at least the elements of it used by 
your code .

It would be good to hear the opinions of other chart users.

Tim


On 23/03/13 03:50, Ben Gamari 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