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

Dimitri DeFigueiredo defigueiredo at ucdavis.edu
Sun Oct 11 02:09:57 UTC 2015

We write software in teams. Most software development (or at least a 
large fraction of it) requires that more than one person work on the 
same codebase simultaneously. This means that in most software 
development there will *necessarily* be code merges.

Every time we merge our work, on branch A, with that of others, on 
branch B, using git or most other tools we are doing a simple line-based 
merge on text files. This kind of merge can produce an output that 
introduces bugs that were not present on either branch A or B even if 
there are no conflicts. This is terrible! This "merge tool" can create 
bugs by itself out of thin air! Can we have a better merge tool?

Ideally, I would like a merge tool to work like a compiler: If there are 
no conflicts, the merge tool guarantees the merge introduces no new bugs 
(other than those already found in A or B). In other words, the output 
of the merge tool is "merge bug free", if there are no conflicts. 
Unfortunately, this is rather tall order. Previous research found that 
for many languages it is impossible to write such a tool [1]. However, 
this may be asking the wrong question.

Let's take a different point of view. Let's assume there will be 
software merges (and therefore that merge tools will be used in software 
development), here are better questions to ask:
1. How does the desire for a "compiler-like" merge tool constrain 
language design? Can we design a language for which such a merge tool is 
2. If it is not possible to get the guarantee that no bugs will be 
introduced during the merge process, what guarantees can we get? Can we 
at least get that at the module level? Does that constrain the available 
design space?

Specializing those to Haskell:
1. Can we write a "compiler-like" merge tool for Haskell?
2. If not, can we tweak Haskell so that the existence of such a tool 
becomes possible? Can we at least get that at the module level?



[1] D. Binkley, S. Horwitz, and T. Reps. 1995. Program integration for 
languages with procedure calls. /ACM Trans. Softw. Eng. Methodol./ 4, 1 
(January 1995), 3-35.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151010/5c4051cb/attachment.html>

More information about the Haskell-Cafe mailing list