darcs

Patch 1947 refactor simplifyPush (and 9 more)

Title refactor simplifyPush (and 9 more)
Superseder Nosy List ganesh
Related Issues
Status needs-review Assigned To
Milestone

Created on 2019-09-27.20:00:02 by ganesh, last changed 2019-09-28.12:09:25 by ganesh.

Files
File name Status Uploaded Type Edit Remove
add-haddock-to-pushfixupfn.dpatch ganesh, 2019-09-28.12:09:25 application/x-darcs-patch
patch-preview.txt ganesh, 2019-09-27.20:00:01 text/x-darcs-patch
patch-preview.txt ganesh, 2019-09-27.20:33:32 text/x-darcs-patch
patch-preview.txt ganesh, 2019-09-28.12:09:25 text/x-darcs-patch
refactor-simplifypush.dpatch dead ganesh, 2019-09-27.20:00:01 application/x-darcs-patch
refactor-simplifypush.dpatch ganesh, 2019-09-27.20:33:32 application/x-darcs-patch
unnamed ganesh, 2019-09-27.20:00:01 text/plain
unnamed ganesh, 2019-09-27.20:33:32 text/plain
unnamed ganesh, 2019-09-28.12:09:25 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg21644 (view) Author: ganesh Date: 2019-09-27.20:00:01
I am not screening this immediately, but would like to do so
soon if there are no objections.

It's a series of incremental refactors to turn the rather
monolithic definition of simplifyPush into more modular pieces
that we'll be able to reuse when refactoring the rebase types.

It was initially part of my WIP bundle for migrating rebase
to use prim types everywhere, but I've factored it out to be
applyable first even though it adds a bit more complexity
(the code is simpler with prims). I think it's worth it to break
the merging work into smaller pieces.

Some of the changes are quite small, reflecting the way I
actually did the refactoring.

mapMB_MB can obviously be replaced with fmap2 if we apply
the Functor2 patch.

10 patches for repository darcs-unstable@darcs.net:screened:

patch 393574cfc5cbccd959c0f9a14c2e9d9eed4f0ab9
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:15:09 BST 2019
  * refactor simplifyPush
  
  This patch introduces a general concept of pushing 'fixups'
  past 'items', and uses it to implement simplifyPush.
  
  This provides a framework for modularizing the logic in
  subsequent patches.

patch fcc84f7dfb92f769a649bfbdd5ba6aba639f4280
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:19:06 BST 2019
  * drop redundant case in pushFixupItem

patch 17f854155bbacb52bf2ab974e04fcb82a2e56d00
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:19:28 BST 2019
  * drop error in commuteNameNamed if a deleted name is readded
  
  As in D.P.R.Item.pushFixupItem, this scenario isn't impossible
  so should just be a failed commute rather than an error.
  

patch 287c8c901e9ba38e018dfeef7c79cf2473edd563
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:21:22 BST 2019
  * reuse commuteNameNamed to push RebaseName through ToEdit
  
  A commute is the natural way of implementing this operation
  and following the previous refactors the logic was identical

patch f7235ff1566651fe2f04dac2a71d103b3edd9435
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:32:01 BST 2019
  * add Maybe2 type

patch 2283cc4f2f6a131728fbcd0a622a9bc49f7458cd
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:32:08 BST 2019
  * move logic for pushing name fixups to D.P.R.Name

patch 08e571529264913630083abe368ef355a5d4195b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:40:03 BST 2019
  * move logic for pushing prim fixups to D.P.R.Fixup

patch 9f3996fbc438da7df101b85535aa760077fbcab3
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:41:40 BST 2019
  * reorder cases in pushFixupItem
  
  Just to make it easier to see how connected logic can be
  extracted to a separate function.

patch 3e3ebc087fb95171de2fc1ed7befc0b111135289
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:50:20 BST 2019
  * move logic for pushing past fixups into D.P.R.Fixup

patch 7fa75673d2f15d74320b510f557b6d19fdbc004e
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:53:55 BST 2019
  * use commuteFixupNamed in pushFixupItem
Attachments
msg21645 (view) Author: ganesh Date: 2019-09-27.20:33:32
resending to amend out trailing whitespace in the last patch

10 patches for repository darcs-unstable@darcs.net:screened:

patch 393574cfc5cbccd959c0f9a14c2e9d9eed4f0ab9
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:15:09 BST 2019
  * refactor simplifyPush
  
  This patch introduces a general concept of pushing 'fixups'
  past 'items', and uses it to implement simplifyPush.
  
  This provides a framework for modularizing the logic in
  subsequent patches.

patch fcc84f7dfb92f769a649bfbdd5ba6aba639f4280
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:19:06 BST 2019
  * drop redundant case in pushFixupItem

patch 17f854155bbacb52bf2ab974e04fcb82a2e56d00
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:19:28 BST 2019
  * drop error in commuteNameNamed if a deleted name is readded
  
  As in D.P.R.Item.pushFixupItem, this scenario isn't impossible
  so should just be a failed commute rather than an error.
  

patch 287c8c901e9ba38e018dfeef7c79cf2473edd563
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:21:22 BST 2019
  * reuse commuteNameNamed to push RebaseName through ToEdit
  
  A commute is the natural way of implementing this operation
  and following the previous refactors the logic was identical

patch f7235ff1566651fe2f04dac2a71d103b3edd9435
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:32:01 BST 2019
  * add Maybe2 type

patch 2283cc4f2f6a131728fbcd0a622a9bc49f7458cd
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:32:08 BST 2019
  * move logic for pushing name fixups to D.P.R.Name

patch 08e571529264913630083abe368ef355a5d4195b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:40:03 BST 2019
  * move logic for pushing prim fixups to D.P.R.Fixup

patch 9f3996fbc438da7df101b85535aa760077fbcab3
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:41:40 BST 2019
  * reorder cases in pushFixupItem
  
  Just to make it easier to see how connected logic can be
  extracted to a separate function.

patch 3e3ebc087fb95171de2fc1ed7befc0b111135289
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 20:50:20 BST 2019
  * move logic for pushing past fixups into D.P.R.Fixup

patch efe5448f9d159779df7ebf47099bcd5cd249d2b5
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Sep 27 21:38:04 BST 2019
  * use commuteFixupNamed in pushFixupItem
Attachments
msg21648 (view) Author: bf Date: 2019-09-27.22:50:00
> I am not screening this immediately, but would like to do so
> soon if there are no objections.
> 
> It's a series of incremental refactors to turn the rather
> monolithic definition of simplifyPush into more modular pieces
> that we'll be able to reuse when refactoring the rebase types.

You are obviously approaching this in a way that is quite different from
how I would do it. This is not surprising of course and by all means do
it your way. Just to get it out of my system: I think your step-by-step
refactors is wasting effort on code that is unnecessarily complicated to
begin with, due to the mixing of different types of things (RebaseFixup
mixed fixups with name fixups, RebaseItem mixes suspended patches with
both name and normals fixups). I would rather spend effort on separating
them which I am convinced will make everything a lot simpler. This is
not easy to do in small steps, I understand that, but at some point you
will have to bite the bullet and just plunge ahead.

Now, with that out of the way, your changes look okay to me, so go ahead
and screen them. I find it difficult to check them for correctness in
detail, though. One reason is that I am not familiar enough with the
existing code. Another is lack of documentation. I would like to suggest
that if you find it worth to refactor the existing functions you might
as well add haddocks to them while you're at it. It is always easier to
understand a change when you know the precise purpose of the code. (Some
of it can be guessed from the names but not everything.)

I would personally prefer to review a final version because that doesn't
require me to understand all the steps of how you got there from the
current situation. But we cannot always have it all as we like it, can we?

(BTW, I think this is at least partly the fault of darcs because darcs
diff has no interactive mode. I am missing that a lot when reviewing
bundles that consist of many small patches. I want to traverse my
patches and say: "show me this patch in meld".)
msg21650 (view) Author: ganesh Date: 2019-09-27.23:23:12
I should definitely have written a haddock for PushFixupFn, I'll
do that asap. simplifyPush itself, which is the thing I'm ultimately
refactoring, already has a haddock. Do you want to see haddocks on
the individual functions I'm introducing? They'd basically amount to
"push x past y", for varying values of x and y.
msg21653 (view) Author: ganesh Date: 2019-09-28.12:09:25
1 patch for repository darcs-unstable@darcs.net:screened:

patch be525464af7dd4a365a7bb84cbefdf040addea28
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Sat Sep 28 13:10:16 BST 2019
  * add haddock to PushFixupFn
Attachments
History
Date User Action Args
2019-09-27 20:00:02ganeshcreate
2019-09-27 20:33:32ganeshsetfiles: + patch-preview.txt, refactor-simplifypush.dpatch, unnamed
messages: + msg21645
2019-09-27 22:50:00bfsetmessages: + msg21648
2019-09-27 23:23:12ganeshsetstatus: needs-screening -> needs-review
messages: + msg21650
2019-09-28 12:09:25ganeshsetfiles: + patch-preview.txt, add-haddock-to-pushfixupfn.dpatch, unnamed
messages: + msg21653