[darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?

Florent Becker florent.becker at ens-lyon.org
Tue Sep 30 18:54:35 UTC 2008


Thanks for the very nice explanation! Does that mean that we have the  
invariant that in
PIAP i (Hopefully Actually p), we have p = (Named i _ _), the two i  
being the same?

Florent

Le 30 sept. 08 à 20:18, Jason Dagit a écrit :

>
>
> On Tue, Sep 30, 2008 at 8:08 AM, Florent Becker <florent.becker at ens-lyon.org 
> > wrote:
> Hi list,
>
> as a newbie darcs hacker, i have a ton of naïve questions. If you  
> don't
> mind me asking them, i'll try to compile your answers into darcs-doc
> strings in the code for the next generation of darcs hackers.
>
> The first one is: what problem does the 'PatchInfoAnd' type solve? Why
> don't we call 'Darcs.Patch.Core.patch2patchinfo' everywhere, and  
> what is
> the Hopefully for?
>
> The problem solved by PatchInfoAnd is the one where you know the  
> info for a patch and you may be able to fetch that patch but you're  
> not certain.  This comes up in the following scenario: Imagine  
> reading a patch info from an inventory and then still being faced  
> with the problem of finding the patch either in the local  
> repository, the cache, or needing to fetch the patch lazily.  I'm  
> not sure if this code is used with partial repos, but it may help  
> there as well.
>
> It works like this:
> data Named p C(x y) where
>   NamedP :: !PatchInfo -> ![PatchInfo] -> !(p C(x y)) -> Named p C(x  
> y)
> data Hopefully a C(x y) = Hopefully (SimpleHopefully a C(x y)) |  
> Hashed String (SimpleHopefully a C(x y))
> data SimpleHopefully a C(x y) = Actually (a C(x y)) | Unavailable  
> String
> data PatchInfoAnd p C(a b) = PIAP !PatchInfo (Hopefully (Named p)  
> C(a b))
>
> patch2patchinfo :: Named p C(x y) -> PatchInfo
> patch2patchinfo (NamedP i _ _) = i
>
> Clearly, we see that given any Named patch we can use  
> patch2patchinfo to get the patch info.
>
> As in the thread Eric pointed you to, you can see that  
> SimpleHopefully really a new name for 'Either String (a C(x y))',  
> but then we added one more layer on top of that, called Hopefully,  
> and we can see that Hopefully is equvalent to:
> Either (Either String (a C(x y))) (String, (Either String (a C(x y))))
>
> I think I have that right, the right side of Hopefully is a bit  
> tricky.  Clearly it's better to give our own data type.  Nested  
> Eithers are just ugly.
>
> Back to the point.  SimpleHopefully encodes the fetchable status of  
> the patch.  We either 'Actually' have the patch or it's  
> 'Unavailable'.  I'm not sure what we store in the unavailable  
> String.  We might store the location of the patch or we might store  
> an error string. I'd have to dig deeper to know.  Maybe you could do  
> that or someone else could answer the question.
>
> Now that we store whether the patch is available we have another  
> layer in Hopefully.  In Hopefully we either have just a plain old  
> darcs patch or we have one of the fancy newer patches that comes  
> with a hash, eg., Hashed String (SimpleHopefully a C(x y)).
>
> Then we have Named, which just stores a patch and it's info (which  
> is the name).  With a Named there is no uncertainty about whether  
> you have the patch, it's here and ready to be examined.  Whereas  
> you'll notice lots of functions in the Hopefully module that are for  
> looking up patches and dealing with the error cases.
>
> I hope this helps,
> Jason
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20080930/2430c881/attachment.htm 


More information about the darcs-users mailing list