Sorry, I should have given a heads-up.  Patch review is going to be
delayed this week, perhaps until next weekend.  Here's what I have so
far.

> replace ./src/Darcs/Patch/Commute.lhs [A-Za-z_0-9] commute commutex

ok for me... nowawadays we write commutex (y :< x), and now we will be
able to write                    commute  (x :> y), which is the same

Minor note: some documentation and error messages are hit by this
commute to commutex change, may be worth looking into when the dusts
settles

> +                           , _cancelled  :: ![Int]
> +                           , _conflicted :: ![Int]

guess these should not have snuck in here.  too bad

> +    commute (xs :> ys) = do ys' :> rxs' <- commuteRLFL (reverseFL xs :> ys)
> +                            return $ ys' :> reverseRL rxs'

Seems to make sense.  Using informal eric notation with the obvious
intended meaning.

The idea is that
  commute (FL [a,b,c]) :> (FL [d,e])
should give you roughly
          (FL [d',e']) :> (FL [a',b',c'])

> +commuteRLFL :: Commute p => (RL p :> FL p) C(x y) -> Maybe ((FL p :> RL p) 
> C(x y))

commuteRLFL (RL [c, b, a]) :> (FL [d,e]) is
  #1 commute RL [c ,b ,a ] :> d,
  #2 commute RL [c2,b2,a2] :> e...
  #3 return FL [d',e'] :> RL [c',b',a']

> +commuteRL :: Commute p => (RL p :> p) C(x y) -> Maybe ((p :> RL p) C(x y))
> +                               w'' :> zs' <- commuteRL (zs :> w')
> +                               return (w'' :> z' :<: zs')
> +commuteRL (NilRL :> w) = Just (w :> NilRL)

commute (RL [c, b, a]) :> d  is
  #1 commute (c :> d)
  #2 commute (b :> d2)
  #3 commute (a :> d3)...
  #4 return d4 :> RL [c2,b2,a2]

> +commuteFL :: Commute p => (p :> FL p) C(x y) -> Maybe ((FL p :> p) C(x y))

checked

> +instance Invert p => Invert (RL p) where
> +    invert = reverseFL . invertRL

invert (RL [c,b,a]) is
 # FL [c^,b^,a^]
 # RL [a^,b^,c^]

> +invertFL :: Invert p => FL p C(x y) -> RL p C(y x)
> +invertRL :: Invert p => RL p C(x y) -> FL p C(y x)

check... note inversion taken care of by type switch

> [Move ReadPatch stuff into yet another class.
> David Roundy <[EMAIL PROTECTED]>**20070904210525] 

> +instance ReadPatch p => ReadPatch (FL p) where
> +    readPatch' want_eof = do "{" <- sal_to_string `liftM` work my_lex
> +                             Just `liftM` read_patches
> +     where read_patches :: (Stringalike s, ParserM m, Monad (m s))
> +                           => m s (Sealed (FL p C(x )))

This is just read_patches from Darcs.Patch.Read with one less parameter.
The old read_patches is kept for parsing split patches.  Is that going
away sometime soon?

=======================================================================
Define class for apply.
=======================================================================

ok

=======================================================================
make merger code use RL/FL.
=======================================================================


and now refuses to deal with any merger patches prior to the 0.0 version
(e.g. 0.9)... I guess this is the end of the phase-out part

i didn't understand all of this, but I got the basic gist that we are
using the new RL/FL types, and are using Merger/Regrem instead of
Merger True and False.

i have not attempted to verify if you are using the lists in the right
directions :-)

Concern: should unwind accept Regrem patches? I ask because the old
code does not specifically ask for Merger True

> -commute_recursive_merger (Merger True _ _ _ _ _ :< _) = impossible

cases like these were for non 0.0 mergers

> +filenames (Merger p ps p1 p2) = filenames $ Regrem p ps p1 p2
> +filenames (Regrem p ps p1 p2) = filenames p ++ filenames p1 ++
> +                                filenames p2 ++
> +                                concat (mapFL filenames $ reverseRL ps)

should i worry about filenames coming out in the wrong order?


-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.

Attachment: pgp5VexOddLXt.pgp
Description: PGP signature

_______________________________________________
darcs-devel mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-devel

Reply via email to