For me, there are two separate issues in the debate over commuting diagrams packages; what's best for drawing simple square diagrams quickly, and what is best for achieving complex effects (non-square symmetries, lots of 2-cells, for instance). I don't like Paul's syntax for either. My objection on the first count, and the reason I like Mike's proposal, is just taste; in honesty, I think either Paul's or Mike's syntax would be reasonable for producing quick-and-easy square diagrams, even if some of us execrate the syntax. The second point is more serious; just how much of a graphics package do we want a commutative diagrams package to be? Should I be able (albeit with lots of effort) to draw pentagonal diagrams or complex interactions between 2-cells (such as in, for instance, Mike Johnson's thesis) ? Having tried to use it, I don't think Paul's package will extend cleanly in this direction. Mike's syntax might leave one with having to draw a complex diagram on graph paper first, but that is better than not being able to draw it at all, and is something that frankly ought to be done unless one is very sure of the way the results will look on the page. In summary, then, I don't believe a package that calculates its own positions for things (rather than leaving that up to the user) can achieve the highest standards for a wide class of diagrams. We must define the problem--what is the class of things we want to draw ? If it includes pentagons, heptagons,... then we may end up forcing people to do trigonometry. David Murphy +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++