search

diagrams / diagrams-lib

Diagrams standard library
https://diagrams.github.io/
Other
138 stars 62 forks source link

Path+trail editing, with zippers! #49

Open byorgey opened 12 years ago

byorgey commented 12 years ago

Use edwardk's lens library to make some zippers over paths/trails, to make it easy to edit them.

There are probably lots of other cool things that could be done along these same ideas (not necessarily all involving lens).

mgsloan commented 12 years ago

Question is, where do I put it! I don't think that we want a dependency on lens in diagrams-lib or diagrams-contrib

Maybe time to make diagrams-lens ?? :D

byorgey commented 12 years ago

Honestly, I'm not worried about a lens dependency, even in diagrams-lib. Here's my reasoning:

  1. diagrams-lib already depends on many of lens's dependencies.
  2. The other ones (e.g. text, bytestring) are all fairly standard, stable packages and I don't mind pulling them in as transitive dependencies.
  3. Edward is always super responsive about fixing packages should we run into any issues.

That said, perhaps diagrams-contrib is the best place for it, at least at first.

byorgey commented 12 years ago

Also, I'm excited if this means you're planning to start doing some diagrams hacking again. =)

mgsloan commented 11 years ago

Yup, definitely hoping to get in more diagrams hacking :D Busy with other stuff, but ought to be able to get a few cycles in here and there.

I've started a small file of diagrams lenses, with just a few definitions, you get a pretty decent for-free zipper on paths. However, when trying to use it I noticed that it does not have a natural way of expressing "insertion" into a level. This is certainly by design, as a level is a traversal. However, you should also be able to get a level-supporting-insertion if you have a lens that yields a list. I'll talk to edward about the best way to do this.. Might be best to just have the focus be a list-zipper, but then you can't use the normal navigation commands.

BTW, if we can have an isomorphism between paths and [[FixedSegment]], then we definitely get a zipper that can operate on them.

One interesting thing is that as long as you stick to lenses / traversals, a dependency on diagrams isn't necessary! Though a dependency does make the types nicer.

mgsloan commented 11 years ago

Strangely, I don't see nandykins' comment "Isn't the whole point of lens that it doesn't actually require any dependencies on ‘lens’ itself, if you're just writing lenses?" in the github UI.

Well, no, that's not the whole point ;)

It is quite a nice property, though. However, I did write some isomorphisms for diagrams. WIthout a dependency, I can't write them. These could be represented as lenses, but only somewhat dishonestly. Also, in absence of a dependency on lens, the types might look a little scary + not usefully link to the library that goes with them.

Maybe I'll lobby edward for a "lens-core", that merely exports stuff that's useful to providers of lens-like things. I dunno, at once it's kindof nice to have one library. On Wed, Oct 17, 2012 at 11:19 AM, nandykins notifications@github.comwrote:

Isn't the whole point of lens that it doesn't actually require any dependencies on ‘lens’ itself, if you're just writing lenses?

— Reply to this email directly or view it on GitHubhttps://github.com/diagrams/diagrams-lib/issues/49#issuecomment-9537976.

byorgey commented 11 years ago

I was wondering the same thing re: @nandykins' comment. Perhaps it got deleted. Anyway, yeah, even for the type signatures alone I'd rather be able to have a dep on lens and be able to write things like foo :: Simple Lens blah rather than some gobbledygook with lots of arrows and foralls and who knows what.