Page 5: "The geo-server specification was by nature ambiguos and imprecise, thus leading to some variation in the functionalities of developed prototypes. (On the other hand, the specification is probably typical of that found in practice, especially during requirement acquisition.)"
Nevertheless, at Page 6 starts the chapter 3 which aptly named "Problem description".
The Haskell code for a problem solution is at Page 15. It is not complete, but it contains examples of what is called "combinators", from whose it is easy to deduce how authors approached the solution.
But, one needs to be aware of the notion of combinators and how they are usually constructed. For that, take a look at [1], a construction of parsing combinators. They start with a simple higher-order functional approach just like the solution exemplified in the paper we all discuss here.
Nevertheless, at Page 6 starts the chapter 3 which aptly named "Problem description".
The Haskell code for a problem solution is at Page 15. It is not complete, but it contains examples of what is called "combinators", from whose it is easy to deduce how authors approached the solution.
But, one needs to be aware of the notion of combinators and how they are usually constructed. For that, take a look at [1], a construction of parsing combinators. They start with a simple higher-order functional approach just like the solution exemplified in the paper we all discuss here.
[1] https://www.researchgate.net/publication/222837975_Combinato...