On Wed, Jun 13, 2007 at 09:27:10PM +0200, Eric Y. Kow wrote: > On Tue, Jun 12, 2007 at 21:05:11 -0700, David Roundy wrote: > > Here's the next installment of the gradual march towards type > > witnesses. > > Exciting! > > Here's the current compilation error: > src/Darcs/Patch/Show.lhs:34:26: > Module `Darcs.Patch.Core' does not export `unsafeUnFL' > > Do you guys want this stuff in despite the compilation errors? > (compiles fine without --with-type-witnesses)
Yeah, that's the plan. As long as it works fine without --with-type-witnesses, the plan is that we'll convert modules to use type witnesses one at a time. And converting *all* of darcs is not currently on our timetable. For the moment, we just want the safety in the core. Eventually I'd like to see it throughout, but it's not a high priority right now. > I should read (p1 :< p2) as p1 before p2, right? No, that would mean p1 after p2. Do you find the arrow more intuitive the other direction? > Also, I wonder if we want > :< and > :>: to be different directions... The idea is that (p2 :< p1) means p1 before p2 (notice that I changed their order) and that (p1 :>: ps) means p1 before ps. We'd rather move over to using :>, as in (p1 :> p2), but that would involve greater modifications to the code than I'm comfortable with in the absence of type witnesses. Our current refactor has the safety advantage in that it doesn't reorder anything. Jason's change Tue Jun 12 13:16:46 PDT 2007 Jason Dagit <[EMAIL PROTECTED]> * Commute has arguments backwards was when we realized that the existing tuple argument to commute is in the reverse order of the way we currently write commutes notationally. Once we have the gadt stuff throughout the code, it'll be "safe" to reverse the order of this input. Until then, I'm afraid we'd miss the reversal somewhere, and introduce a rarely-troublesome bug. > > hunk ./src/Darcs/Patch/Depends.lhs 419 > > - Just (p', fir') -> ctt (p':las) fir' ps > > - cmt_by :: ([Patch], Patch) -> Maybe (Patch, [Patch]) > > - cmt_by (ps, a) = do (a', jps') <- commute (join_patches ps, a) > > - return (a', flatten jps') > > + Just (p' :> fir') -> ctt (p':las) fir' ps > > + cmt_by :: [Patch] :> Patch -> Maybe (Patch :> [Patch]) > > + cmt_by (ps :> a) = do (a' :> jps') <- commute (join_patches ps :> a) > > + return (a' :> flatten jps') > > Should commute_to_end give (Patch, Patch) or (Patch :< Patch)? Hmmm. I think you're right. But it's also a function that I don't think we are going to gadtize in the near future, since we don't yet have plans for when we'll gadtize PatchSet. > > -mapFL :: (FORALL(w y) a C(w,y) -> b C(w,y)) -> FL a C(x,z) -> FL b C(x,z) > > -mapFL _ NilFL = NilFL > > -mapFL f (a:>:as) = f a :>: mapFL f as > > +mapFL_FL :: (FORALL(w y) a C(w,y) -> b C(w,y)) -> FL a C(x,z) -> FL b > > C(x,z) > > +mapFL_FL _ NilFL = NilFL > > +mapFL_FL f (a:>:as) = f a :>: mapFL_FL f as > > + > > +mapFL :: (FORALL(w z) a C(w,z) -> b) -> FL a C(x,y) -> [b] > > +mapFL _ NilFL = [] > > +mapFL f (a :>: b) = f a : mapFL f b > > Hmm... maybe mapFL should give FL, and something like mapFL_List should give > [] > Seems more intuitive anyway. I don't know. I was tired when making that decision and finally decided it's easy to change so I'd just go with something. I'll see what Jason thinks, and we can change it. Maybe forgetting the caps and going with something like map_f2f and map_f2l, and reverse_r2f, reverse_f2r would make sense. > Also, you might find something like a concatMapFL handy. Indeed. I partly delayed this simply because of the awkwardness of the naming. Should it be concatMapFL :: (a -> FL b) -> FL a -> FL b or concatMapFL :: (a -> [b]) -> FL a -> [b] ? But yeah, we can duplicate all of Data.List. And in the long run, we probably want to do so (including rules pragmas for deforestation). -- David Roundy Department of Physics Oregon State University
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
