[darcs-users] Standards about using unsafeCoerceP(2)

[Max Battcher]

Rob Hoelz wrote:
> Hello Darcs devs and users,
> 
> I've been working on issue #291 for a couple of days now, and after
> reading up on type witnesses and all that stuff, I think I finally
> understand them and their role in Darcs' code.  However, in my
> implementation of the "'e' is for 'edit'" feature, I've come across a
> snag that I believe necessitates the use of unsafeCoerceP.
> 
> What happens is I have an FL of hunks that apply to a file when
> recording.  When the user hits 'e', Darcs drops into an editor and
> accepts their changes.  After the editor exits, I rescan the file for
> hunks.  Let's say that our old hunk list is (1, 2, 3, 4, 5), and our
> user hits 'y' for 1 and 2, then 'e' for 3.  Now suppose that the user
> alters change 3 (resulting in a change we'll call 6), and removes
> change 4 altogether.  Our new list of changes is now (1, 2, 6, 5).
> When Darcs resumes, the user shouldn't have to press 'y' for 1 and 2
> again, so my code attempts to compare the two patch lists and find the
> largest common prefix.  Unfortunately, because of type witnesses, my
> comparison function will not compile.  Again, I don't think I can do
> this without unsafeCoerce (but I would be happy to accept and implement
> suggestions!)
> 
> So, when is it ok to use unsafeCoerceP(2), and do you think it's
> necessary in this case?

Right now I can only really answer the second half of your question, but 
it seems to me that it would be entirely reasonable to go with the 
simpler code in this case: I don't see a huge problem in forcing the 
user to start at the beginning of the hunk list for an edited file.

As a user I can entirely understand "well I edited this file and now I'm 
asked about the changes in the file that I already agreed to, but that 
was before changing that file" as a reasonable compromise to save 
over-complicating the code too much...

--
--Max Battcher--
http://worldmaker.net