Hmmmm. I'm not aware of a relevant paper or talk.
Sealed is needed (well, either sealed or unsafeCoerce#) for readPatch
because readPatch might return an identity patch. It's also needed for
safety reasons, but the identity patch is the reason the compiler wants
it. If we wrote
readPatch :: String -> Patch C(x,y) -- this is a simplified type for clarity
then this would mean that for any string, readPatch can return a patch from
any context to any other context. The problem is that when you run
readPatch "{}"
you want to get back an identity patch, but readPatch can't do this. We
could do this using unsafeCoerce# inside readPatch, but a cleaner solution
is to return a Sealed Patch
readPatch :: String -> Sealed (Patch C(x,))
which hides the final state in an existential. To find out what this final
state is, you have to open up that package. If you open up the package and
find (ComP NilFL), then you know it's an identity patch and you know what
the final state is.
I hope that's clear. I know it's pretty brief. My implementation actually
uses unsafeCoerce# internally when parsing Conflicted patches. We could
have avoided this by storing the inverse of the conflicted patch and its
context, but it didn't seem worth the change. The code would have been
more elegant, but I think the patches would have been more confusing.
David
On Sat, Jun 16, 2007 at 08:42:01AM -0700, Jason Dagit wrote:
> David,
>
> I'm trying to understand your most recent changes but I'm not quite
> getting the Sealed type. I understand, Sealed (Patch C(x,)) makes the
> 'y' existentially quantified, which basically hides it, but I don't
> understand why that's needed. I think the only place I was studying
> the use so far was in Read.lhs.
>
> Is there a paper or talk I can study to develop a better understanding?
>
> Thanks,
> Jason
>
> On 6/15/07, David Roundy <[EMAIL PROTECTED]> wrote:
> >Hi Eric,
> >
> >This is a rather massive set of patches, which brings you up
> >to our current state of gadt-integration. It also defines the
> >Conflicted patch type, but doesn't create it, so this should
> >be safe.
> >
> >David
_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
