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 possible? 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? Cheers, Dimitri [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.