coder . cl

Most modern applications are providing APIs. That allows you to integrate those applications providing APIs with third party applications and create a real cloud computing environment. From an architectural perspective, we should have at least to have in mind the architectural pattern to be used, design patterns to be implemented, the protocol to use and the data format to expose the API. The architectural pattern should be simple, the design pattern efficient, the protocol lightweight and the data format flexible for your requirements. With a good API design, it should be stable enough to support changes along the time dynamically.

Programming in Haskell is cool. You have various functions and abstractions to work with. But it has several considerations to have in mind once you are programming in this language. The main one about its performance and memory usage — in my opinion — is where to place lazy evaluated expressions and where to place strictly evaluated expressions. There are various articles with very good recommendations, but I want to show you a practical example, where you can see how effectively is used the lazy evaluation and released in a good execution point of the example program.

I have started my own solutions to the Project Euler in Haskell. Just to practice Haskell and its features. The past problem was the problem 255. Now I have solved the problem 102, using some additional features, not taking the problem as it comes in the Project Euler. Rather than doing a simple solution in plain text, I have created a program which renders the triangles in the problem using OpenGL, placing the triangles in a Windows rather than just indicating the number of triangles.

Haskell is a fabulous language, there is no looping instruction like for or while, everything is stated using recursions, like any other functional language does, preventing states across the execution, as it was defined on the computational model of most functional languages, which is known as λ-Calculus. There is no state, only purely functional state-less execution paths. The Problem 255 on the Project Euler, is related to rounded squares and the Heron’s method to calculate it, so I have implemented a Haskell program with that algorithm, which is obviously a recursive algorithm.

The Collatz problem is Math problem related to a pair of operations which applied recursively will make a number reach 1 always. «The Collatz conjecture is a conjecture in mathematics named after Lothar Collatz, who first proposed it in 1937. The conjecture is also known as the 3n + 1 conjecture, the Ulam conjecture (after Stanisław Ulam), Kakutani’s problem (after Shizuo Kakutani), the Thwaites conjecture (after Sir Bryan Thwaites), Hasse’s algorithm (after Helmut Hasse), or the Syracuse problem; the sequence of numbers involved is referred to as the hailstone sequence or hailstone numbers, or as wondrous numbers.»

Take any natural number n. If n is even, divide it by 2 to get n / 2. If n is odd, multiply it by 3 and add 1 to obtain 3n + 1. Repeat the process (which has been called “Half Or Triple Plus One”, or HOTPO[4]) indefinitely. The conjecture is that no matter what number you start with, you will always eventually reach 1. The property has also been called oneness.

As you I am a Haskell programmer. I have started a FOSS project called Apache Log Reviser, or logrev as short name. I have been playing with code optimizations in Haskell on that project. So, I want to share some experience and considerations regarding its memory usage, mainly on what is related to lazy evaluations and non-strict bindings. Where lazy evaluations should be used every time you need to read or write data with delayed behaviour, for example reading large lists or even lazy lists, and non-strict bindings should be used every time you need to request data to be placed on memory for immediate reading or writing.

As you know ApacheLogRev or logrev as short name, is my first Haskell FOSS project — I have other FOSS projects written in C and Python — and I want to share some experiences about logrev while I was developing some features that it should have in the future, because it is still under development and it is not finished yet. Basically, it is using the Parsec combinator based parser. One of the best advantages of this parser builder is the fact that it is generating parsers on run time, rather than creating fixed parsers using BNF grammars which are subject of static context free processing, rather than creating dynamic parsers.