[Chart] data-accessor, lens, and Chart

[Malcolm Wallace]

Well, I have my own DSL for creating charts, which eventually gets translated into the kind of stuff you have below, or native records, or whatever.  I don't much mind what the lower layer consists of, because in my world, I write:

  linePointPlot [(2,3),(4,10),(5,105),(6,2013)]
      |+| Title "Log/Linear example"
      |+| XAxisLabel "horizontal"
      |+| YAxisLabel "vertical"
      |+| YAxisLogScale

I find I can never understand nor remember the subtle differences between ^: and ^= and ^. so writing code with data-accessor is rather hit-and-miss - I just keep trying operators until it compiles.  Since the lens package has the reputation for introducing 99 different operators, I'm not encouraged to learn it either.  I much prefer the restricted world of a single operator.  :-)

Regards,
    Malcolm

On 23 Mar 2013, at 11:00, Tim Docker wrote:

> 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
>