search

diagrams / diagrams-contrib

User-contributed extensions to diagrams
BSD 3-Clause "New" or "Revised" License
27 stars 30 forks source link

Metafont combinators #19

Closed bergey closed 10 years ago

bergey commented 10 years ago

This is a proposal for Metafont combinators, potentially a nicer interface than the text parser or the quasiquoter we've discussed. I'm pretty happy with the three new operators, but not terribly happy with the ways of describing paths, especially directions. Any better ideas?

See also the tutorial on these combinators: https://github.com/diagrams/diagrams-doc/blob/metafont/doc/metafont.rst

I'll submit a separate pull request for that after this one is closed, but I figure the examples may help when reviewing this.

byorgey commented 10 years ago

One possible idea (not sure if it's a good idea or not) is to make Join a monoid, so Just replaces Nothing and otherwise we always take the first (or last) value for some field. This way one could write e.g.

z1.- leaving unitX <> arriving unitY -.z2 .--. endpt z6

and we would no longer need e.g. the directions and controls functions, you could specify both direction and tension, etc.. The only reason I hesitate is that Join is not really all that monoid-y, and it would be easy overspecify a join so that some information is dropped, without it being obvious to the user that's what's going on.

byorgey commented 10 years ago

In general, I really like this though. Can you say a bit more about what exactly you don't like re: specifying directions?

bergey commented 10 years ago

Mostly I am concerned about composition, which your monoid proposal addresses. Also, I would have liked to find a direction syntax that felt more like the Metafont syntax.

Thinking through the monoid. We'd need to pick which side is used when combining two 'Just's; maybe there is a convention. We can change the join type from ´Either TensionJoin ControlJoin´ to ´Maybe (Either TensionJoin ControlJoin)´, where Nothing is the identity for ´mappend´ but defaults to ´tension 1´ if not overridden.

I wonder if it better to make ´leaving´, ´arriving´, and friends functions Join -> Join instead. We can then write def # leaving unitX # tension 1.2. It's a little more verbose, but makes very clear what's going on.

Thoughts? Preferences?

Brent Yorgey notifications@github.com wrote:

In general, I really like this though. Can you say a bit more about what exactly you don't like re: specifying directions?

Reply to this email directly or view it on GitHub: https://github.com/diagrams/diagrams-contrib/pull/19#issuecomment-26188421

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

byorgey commented 10 years ago

To be consistent with other things in diagrams, the convention would be that in j1 <> j2, j2 overrides j1... I think. See, even I am confused about it. Users are certainly not going to have a good intuition for it. Making leaving and friends Join -> Join solves that problem, but I would find it very annoying since now we have to write z1 .- def # leaving unitX -. z2 instead of just z1 .- leaving unitX -. z2. I don't want to write def # at every join.

byorgey commented 10 years ago

Also, I'm not too worried about finding syntax that is like the Metafont syntax. Most users will not know Metafont, so it's more important to just have something simple and consistent.

bergey commented 10 years ago

The commits above add the Monoid instance. I removed directions, but kept controls and tensions. I don't think there are obvious semantics for setting just one control point, and setting one tension is problematic because of things like controls z1 z2 <> leftTension 1.5. Do you agree?

The result is a little funky, but I think the Monoid instance is worthwhile.

byorgey commented 10 years ago

Yeah, that makes sense to me.