Difference between revisions of "Diagrams"

From HaskellWiki
Jump to navigation Jump to search
Line 9: Line 9:
 
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data strcutreus very hard or impossible.
 
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data strcutreus very hard or impossible.
   
* seperate packages for
+
A rewrite of diagrams should include separate packages for:
 
** high-level code (constraint solving)
 
** high-level code (constraint solving)
 
** low-level graphical primitives (rectangles, polygons, paths, etc)
 
** low-level graphical primitives (rectangles, polygons, paths, etc)

Revision as of 11:31, 23 October 2009

The diagrams library provides an embedded domain-specific language (EDSL) for creating simple pictures and diagrams in Haskell


Ideas for the rewrite

Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data strcutreus very hard or impossible.

A rewrite of diagrams should include separate packages for:

    • high-level code (constraint solving)
    • low-level graphical primitives (rectangles, polygons, paths, etc)
      • imho there should be primitive shape typeclass like circles and rectangles having a "convertToPath" function. Backends like SVG can then choose to use a primitive like a rectangle as a polygon or a rectangle
    • conversion backends
      • interactive painting via Cairo
      • pure Haskell PDF conversion via HPDF
      • pure Haskell PNG conversion via ???
      • etc.