
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
+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
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@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