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

[Charles Durham]

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 at 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 <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>
>> 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>
>>> http://www.andres-loeh.de/gdiff-wgp.pdf
>>>
>>> Regards,
>>> Sean
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> 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
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://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/20151014/fd9b2548/attachment.html>