[Chart] data-accessor, lens, and Chart

[Tim Docker]

Without data-accessor (or something akin to it like lens) how would you write this sort of code:

    layout = layout1_title ^= "Log/Linear Example"
           $ layout1_bottom_axis ^: laxis_title ^= "horizontal"
           $ layout1_bottom_axis ^: laxis_reverse ^= xrev
           $ layout1_left_axis ^: laxis_generate ^= autoScaledLogAxis defaultLogAxis
           $ layout1_left_axis ^: laxis_title ^= "vertical"
           $ layout1_left_axis ^: laxis_reverse ^= yrev
	   $ layout1_plots ^= [Left (toPlot points), Left (toPlot lines) ]
           $ defaultLayout1

It's pretty ugly with native record syntax.

Tim

On 23/03/2013, at 9:42 PM, Malcolm Wallace <malcolm.wallace at me.com> wrote:

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