<div dir="ltr">Hmm, I think for Case 2, that there is a case where there is no bug in A or B, but a bug in the merge. If the search strategy changes from s to s', and the function definition changes from f to f', then I can come up with a scenario where s and s' works for f and s works for both f and f', but s' doesn't work for f'. I believe that Case 1 is pretty much the same.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 12, 2015 at 3:20 PM, Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I think both these examples strengthen my argument! :-)<br>
<br>
There is no problem at all in the second and the first one precisely
show us a situation when we would like to know there is a conflict.
<br>
<br>
The guarantee I want is that when merging 2 branches A and B:<br>
*If there are no conflicts*, the merge tool guarantees the merge
output introduces no new bugs *other than those already found in A
or B*.<br>
<br>
Note:<br>
1. we get to define what a conflict is and <br>
2. we don't care if the bugs were already present in either branch.<br>
<br>
On the first example, I assume both branches A and B will compile
and run before the merge so that we are really only changing the
value of the variable on branch A and the definition of the function
on branch B (otherwise the branches would not compile before the
merge).<br>
<br>
Because the definition of the function depends on a *specific* value
the variable, there is no way to avoid declaring a conflict. But
notice that in the more general case where the function puts that
value as a parameter there is no conflict, because if there were a
bug it would already be present in branch B. So, the merge process
is not introducing any bugs by itself.<br>
<br>
This is exactly what happens in the second example. I assume branch
A provides the new definition of f(x) and that in branch B we change
the search strategy in the search function g. However, I assume that
g would take f as a parameter g:: (Integer -> Integer) ->
Integer. In this case, if there were a bug in g in the merged
output, then it would already be present in branch B before the
merge. Therefore, there is no conflict at all here.<br>
<br>
In summary, there is no conflict on the second example and I would
like to know about the conflict due to the global dependency on the
first one.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Dimitri</font></span><div><div class="h5"><br>
<br>
<br>
<div>On 10/11/15 6:58 PM, Charles Durham
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>1. If you have a merge take place in two lines right next
to each other, say one variable is declared in one and a
function processes that variable in another, if those two are
responsible together for exiting a loop, then you're going to
be solving the Halting Problem to show there are no bugs.<br>
</div>
<div><br>
</div>
<div>2. If you have one function "f(x) = a + bx + cx^2 +..." and
another function that iterates through integers until a
solution is found in integers, then if the internals of either
is changed (either the constants in f, or the search
strategy), then you're going to have to be solving "Hilberts
10th Problem" to understand that there are no bugs introduced,
thought this was interesting as the changes are "further"
apart.</div>
<div><br>
</div>
<div>At least for the general case, this should be a problem for
all Turing Complete languages. It might be interesting to
think about finding sections of code that are "Total", and
perhaps put certain guarantees on that, but there still might
be weird ways that two lines of code can play with each other
beyond that.</div>
<div><br>
</div>
<div>I hope this isn't overly pedantic, or that I'm not
completely off base. </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Oct 11, 2015 at 8:10 PM,
Jeffrey Brown <span dir="ltr"><<a href="mailto:jeffbrown.the@gmail.com" target="_blank">jeffbrown.the@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">+1 for AST merge. Writing code from text is
reasonable, but storing code as text is lunacy.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Sat, Oct 10, 2015 at 11:17 PM, Sean
Leather <span dir="ltr"><<a href="mailto:sean.leather@gmail.com" target="_blank"></a><a href="mailto:sean.leather@gmail.com" target="_blank">sean.leather@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra"><span>
<div class="gmail_quote">On Sun, Oct 11,
2015 at 4:09 AM, Dimitri
DeFigueiredo wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Can
we write a "compiler-like" merge tool
for Haskell?</blockquote>
</div>
<br>
</span>Merge could be considered to be a
combination of diff and patch. And so you
might want to merge ASTs, which are typically
families of datatypes. Related: Type-Safe Diff
for Families of Dataypes: <a href="http://www.andres-loeh.de/gdiff-wgp.pdf" target="_blank"></a><a href="http://www.andres-loeh.de/gdiff-wgp.pdf" target="_blank">http://www.andres-loeh.de/gdiff-wgp.pdf</a> </div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Regards,</div>
<div class="gmail_extra">Sean</div>
</div>
<br>
</div>
</div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
</blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">Jeffrey Benjamin Brown</div>
</div>
</font></span></div>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Haskell-Cafe mailing list
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>