Re: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design

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. On Mon, Oct 12, 2015 at 3:20 PM, Dimitri DeFigueiredo < defigueiredo@ucdavis.edu> wrote:

I think both these examples strengthen my argument! :-)

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.

The guarantee I want is that when merging 2 branches A and B: *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*.

Note: 1. we get to define what a conflict is and 2. we don't care if the bugs were already present in either branch.

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).

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.

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.

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.

Dimitri

On 10/11/15 6:58 PM, Charles Durham wrote:

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.

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.

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.

I hope this isn't overly pedantic, or that I'm not completely off base.

On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown wrote:

...

+1 for AST merge. Writing code from text is reasonable, but storing code as text is lunacy.

On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather < sean.leather@gmail.com> wrote:

...

On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote:

...

Can we write a "compiler-like" merge tool for Haskell?

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: http://www.andres-loeh.de/gdiff-wgp.pdf http://www.andres-loeh.de/gdiff-wgp.pdf

Regards, Sean

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Jeffrey Benjamin Brown

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe