Difference between revisions of "Diagrams"
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
A rewrite of diagrams should include separate packages for: |
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. |
|
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.