<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body 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.<br>
    <br>
    <br>
    Dimitri<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/11/15 6:58 PM, Charles Durham
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEXAPH7ygrf-35o1W8_9nDEjgkkS8RqzzHexeDpMZGBGSa4t6g@mail.gmail.com"
      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 moz-do-not-send="true"
              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 class="h5">On Sat, Oct 10, 2015 at 11:17 PM, Sean
                    Leather <span dir="ltr"><<a
                        moz-do-not-send="true"
                        href="mailto:sean.leather@gmail.com"
                        target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sean.leather@gmail.com">sean.leather@gmail.com</a></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 class="h5">
                      <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
                            moz-do-not-send="true"
                            href="http://www.andres-loeh.de/gdiff-wgp.pdf"
                            target="_blank"><a class="moz-txt-link-freetext" href="http://www.andres-loeh.de/gdiff-wgp.pdf">http://www.andres-loeh.de/gdiff-wgp.pdf</a></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 moz-do-not-send="true"
                    href="mailto:Haskell-Cafe@haskell.org"
                    target="_blank">Haskell-Cafe@haskell.org</a><br>
                  <a moz-do-not-send="true"
                    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 class="HOEnZb"><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 moz-do-not-send="true"
              href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
            <a moz-do-not-send="true"
              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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Haskell-Cafe mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>