Remove duplicate reference

Author: noelwelsh

src/pages/tagless-final/conclusions.md

@@ -62,6 +62,6 @@ From the library author's point of view, it is a lot more work to create tagless
 
 As always, the applicability of tagless final comes down to the context in which it is used. In cases where the extensibility is truly justified it is a powerful tool. In other cases it just introduces unwarranted complexity.
 
-The term "expression problem" was first introduced in an email by Phil Wadler [@wadler98:ep], but there are much earlier sources that discuss the same issue. One example is [@cook90:oo-adt]. Tagless final was first introduced in [@jacques09:finally-tagless] and expanded on in [@kiselyov12:tagless-final]. It is just one of many solutions that have been proposed to the expression problem. I'm no expert on the wider field of solutions to the expression problem, but of the papers I've read the ones I'd like to highlight object algebras [@oliveira12:object-algebras] and data types à la carte [@swierstra08:data-types]. Object algebras are, in all essentials, the same as tagless final. They were developed in object-oriented languages rather than functional programming languages, making an interesting case of convergent evolution in two distinct, but connected, fields of research. The object algebras paper is also a good read for a more formal, if brief, discussion of the theory behind the concepts we've been dealing with. Data types à la carte [@swierstra08:data-types] is a data, rather than codata, approach to the expression problem, and so makes an interesting contrast to tagless final. I find tagless final much simpler, so we have not explored data types à la carte in this book. Another noteworthy paper is [@10.1145/2692915.2628138], which discuss the duality between data and codata and its implication for embedded domain specific languages.
+The term "expression problem" was first introduced in an email by Phil Wadler [@wadler98:ep], but there are much earlier sources that discuss the same issue. One example is [@cook90:oo-adt]. Tagless final was first introduced in [@jacques09:finally-tagless] and expanded on in [@kiselyov12:tagless-final]. It is just one of many solutions that have been proposed to the expression problem. I'm no expert on the wider field of solutions to the expression problem, but of the papers I've read the ones I'd like to highlight object algebras [@oliveira12:object-algebras] and data types à la carte [@swierstra08:data-types]. Object algebras are, in all essentials, the same as tagless final. They were developed in object-oriented languages rather than functional programming languages, making an interesting case of convergent evolution in two distinct, but connected, fields of research. The object algebras paper is also a good read for a more formal, if brief, discussion of the theory behind the concepts we've been dealing with. Data types à la carte is a data, rather than codata, approach to the expression problem, and so makes an interesting contrast to tagless final. I find tagless final much simpler, so we have not explored data types à la carte in this book. Another noteworthy paper is [@10.1145/2692915.2628138], which discuss the duality between data and codata and its implication for embedded domain specific languages.
 
 Tagless final was introduced using Haskell as the implementation language. The standard encoding in Scala is a direct translation of the Haskell implementation. The improved Scala encoding is my own creation. The use of the single abstract method shortcut was suggested by Jakub Kozłowski.