On Wed, Feb 14, 2007 at 12:36:56AM -0700, Kevin Quick wrote: > ***Side note: I did have to spend a significant amount of time > determining the proper sequencing to utilize when working with > lists of patches, and I presently have the (possibly incorrect) > impression that this is a dangerous part of the internals of > darcs. It is simply too easy to apply "reverse" to a set of > patches and end up with uncommuted reversal of patches, yet > on the other hand, this reversal is sometimes necessary for > the algorithm at hand. I would suggest that subtle patch > re-ordering bugs could be avoided by using a different container > (other than a standard list) that did not allow patch re-ordering > without proper commutation; however, this would be a fairly > pervasive change and would require proper analysis of those > conditions (like complement) where reversal without commutation > seems to be necessary for the algorithm's operation.
Yes, this is very high on our list of improvements to the core of darcs. But alas, as you say, it's a pervasive change, and so it's hard to get the time to make this change. We have some clever ideas how to enforce these properties using phantom type witnesses, which will make it very hard to introduce this sort of bug into darcs. > > > ind_ps = listof . reverse > > > listof = flip (:) [] > > > > Speaking of simplification, it seems like these helpers could be > > rewritten as > > > > ind_ps x = [reverse x] > > listof x = [x] > > They could. My understanding was that by writing them as > pure functions, GHC could more easily recognize their status as > such and perform optimizations based on this knowledge. In the > case of complement, I believe that optimizations are useful because > I believe this to be the most expensive form of pulling because > it requires examination (and commutation) of nearly every single > candidate patch in all specified repositories. > > Note that my use of "believe" several times in the above statement > means that I have not fully proven or empirically tested these and that > they are therefore untested hypotheses on my part. Simple functions like this ghc will be able to implement very efficiently using the easy-to-read variant--I believe. :) -- David Roundy Department of Physics Oregon State University _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
