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

[Dimitri DeFigueiredo]

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 
> <jeffbrown.the at gmail.com <mailto:jeffbrown.the at gmail.com>> 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 at gmail.com <mailto:sean.leather at 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
>
>         Regards,
>         Sean
>
>         _______________________________________________
>         Haskell-Cafe mailing list
>         Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
>     -- 
>     Jeffrey Benjamin Brown
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151012/a6443aae/attachment.html>