On Tue, Aug 12, 2008 at 11:19 AM, <[EMAIL PROTECTED]> wrote: > I don't think I replied to this email, which has some interesting questions > in it. So I'll send a few replies, which may or may not be useful... >
Thanks your answers were very helpful. It's good that we came to many of the same conclusions. I'm feel much better about this stuff than I used to. It's becoming more natural. > > > applyToTentativePristine :: (Effect q, Patchy q) => Repository p C(r u t) > -> q C(r y) -> IO () > > If this applied to pristine I would say, that the patch needs to be in > > context C(r y), but it says it's applying to a tentative pristine. So > does > > that mean it should be q C(t y)? > > Hmmm. I think C(t y) makes sense. But this is an internal function, which > needs to deal with repositories that are in an inconsistent state, so it > might be trickier than that. I ended up going with C(r y), and I think there was even one spot that was problematic using C(t y), but since I didn't feel confident either way I went with C(r y) for now. > I've commented on some of these, and you can ask about more. There's a > fundamental problem with adding type checking in this way, which is that we > don't yet have a framework for adding type witnesses into IO actions. i.e. > any function that changes the "tentative" state really should change the > type witness associate with it, but these functions cannot do this. To do > so would require a new "tricky" monad-like object, as we've discussed in the > past. > > e.g. > > data WIO p C(r u t t') a = WIO (Repository p C(r u t) -> IO a) > > (I'm omitting the p below, partly because I forgot about it, and partly > because I'm lazy) > > (*>>=*) :: WIO C(r u t t') a -> (a -> WIO C(r u t' t'') b) -< WIO C(r u t > t'') b > (*>>*) :: WIO C(r u t t') a -> WIO C(r u t' t'') b -> WIO C(r u t t'') > returnW :: a -> WIO C(r u t t) a > returnW = WIO . const . return > > io :: IO a -> WIO C(r u t t) a > io = WIO . const > > And I wrote more of this email and then lost it. We'd need to rewrite > withGutsOf to accept a WIO as an argument, and we'd make > > withRepoLock :: [DarcsFlag] -> (forall p C(r u). RepoPatch p => Repository > p C(r u u) -> IO a) -> IO a > > and various other changes such as > > tentativelyAddPatch :: RepoPatch p => [DarcsFlag] -> PatchInfoAnd p C(t t') > -> WIO p C(r u t t') () > > Anyhow, this will be a lot of work... Yes, I was thinking of exactly the same structure when I was writing the "mapAdd". You probably saw my comment about constructing a new Repository object on the recursive call. Maybe we can move to what you propose eventually, but it seems there is lower hanging type safety that we can pick first. Oh and that reminds me, I was reminded from writing mapAdd how unsafe the constructors of values with phantoms types can be when you're using the phantoms as witnesses. I need to comment on that in my writing. Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
