Wumpus

Copperbox revision 730.

The Path module has been moved from Core to Drawing...

I've been reading the TikZ manual and guides. In TikZ everything is a path (apart for nodes with text labels and no doubt some other exceptions that I haven't discovered yet). This is a rather profound idea as far as Wumpus is concerned. In other systems - Kamin and Hyatt's FPic, PiScript... - pictures are commands, commands that change the graphics state, extend a path etc. While paths are, of course, prominent they aren't primary, and there are a lot of commands.

Following these examples is why Wumpus is Wumpus - Writer Monad PostScript. PostScript seemed too large to work with syntactically (build an abstract syntax tree and pretty print it), so I made it a command language - write it out as you go. It was quickly apparent that working with commands is unsatisfactory for geometry, hence all the work in Wumpus.Core for points, polygons, curves etc. But I struggled to work out the vector graphics equivalent of CSG or scene graphs for 3D - how to combine elements into a larger structure.

Although the code in Drawing.Basic isn't so good, it does have a mechanism to combine elements - it uses Wumpus as is, turning geometric primitives into a stream of commands and packaging up the stream with it's bounding box as a picture. Essentially this combines elements by making them anonymous. TikZ points to another way, and one that appears to have significant advantages. Paths can be represented syntactically as algebraic types - they already are in the Core.Path module but it isn't used much. Having everything a path would make Pictures much more tangible, possibly removing the need for the Picture Reader monad that I struggled with over the last couple of days.