[Chart] data-accessor, lens, and Chart

[Malcolm Wallace]

As a Chart user, I have always disliked the data-accessor stuff, and tended to avoid it as much as possible.  I think I also dislike lens, and would not use it.  So that's a neutral vote from me.  :-)

Regards,
    Malcolm

On 22 Mar 2013, at 21:08, Tim Docker wrote:

> (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
> 
> 
> _______________________________________________
> Chart mailing list
> Chart at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/chart