[Chart] Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams

[Brent Yorgey]

Hi Jan and all,

Looks like some great progress!  I'm excited. =) Just a couple
thoughts: one, let me know if you want help staring at the funny type
errors with Legend and whatnot.  I'm not familiar with the Chart code
but perhaps I can help figure out a good solution for the abstraction.

My other general comment is that I know you and Tim have talked a bit
about the problems with having font stuff in IO whereas diagrams is
pure.  However, from my point of view it wouldn't be that big of a
deal if Chart produced an IO Diagram rather than just a Diagram.
Maybe I haven't thought about it sufficiently but it seems like this
would be an easy solution to the problem of needing IO.  I'm happy to
talk about it in more detail if you want, and if there are ways that
the diagrams API could change to make any of this easier I'm happy to
discuss that as well. I'm in the middle of some big refactoring anyway
(though don't worry, I don't think it will affect your work on porting
Chart very much).

-Brent

On Mon, Jun 10, 2013 at 05:24:34PM +0200, Jan Bracker wrote:
> Hi,
> 
> Andy: The goal is to abstract Charts from Cairo so we can plug in another
> backend (target is Diagrams). And by that we would also be able to use
> Sunroof through diagrams. Of course in the end it should also be possible
> to implement a Sunroof backend on its own.
> 
> Tim:
> 
>  > Rather than have the CRender monad take an extra parameter, I guess one
> > could just have a separate data type for each backend (ie CRenderCairo and
> > CRenderDiagrams) and have the drawing code abstracted over a typeclass
> > implemented by both. Not sure if this would be better...
> >
> 
>  I tried your approach in a new branch:
> https://github.com/jbracker/haskell-chart/tree/backend-experiment
> 
> It seems to be working quite well. So I started generalizing everything
> outside of the cairo module to use a general ChartBackend m instead of a
> CRender to draw everything. There are a few spots that are giving me a hard
> time:
> 
> Renderable was implemented in terms of CRender. So I added another type
> parameter and that worked fine until I hit Legend. There I also added a
> type parameter. But that blew up the ToRenderable instance. So I had to
> insert a associated type to relate types to each other. After doing so I
> was not able to fix whatever went wrong in Plot.Pie. The 'ToRenderable
> PieLayout' instance gives me this error:
> 
> Graphics/Rendering/Chart/Plot/Pie.hs:121:62:
>     Could not deduce (RenderableT m a0 ~ PieChart)
>     from the context (ChartBackend m)
>       bound by the type signature for
>                  toRenderable :: ChartBackend m =>
>                                  RenderableT m PieLayout -> Renderable m ()
>       at Graphics/Rendering/Chart/Plot/Pie.hs:(117,5)-(125,29)
>     The type variable `a0' is ambiguous
>     Possible fix: add a type signature that fixes these type variable(s)
>     In the return type of a call of `pie_plot_'
>     In the second argument of `($)', namely `pie_plot_ p'
>     In the second argument of `addMargins', namely
>       `(toRenderable $ pie_plot_ p)'
> 
> I think I know what is going wrong, but I have no idea how to specify the
> instance it should use there. Maybe I am just to tired to see the solution.
> 
> Right now I am trying to make things work without extra type parameters,
> though the definitions that are based on CRender are giving me a hard time,
> because then I end up with rank N types.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "diagrams-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to diagrams-discuss+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
>