Deepen Prolog engine, parser and lexer components

[maldins46]

In order to implement the pipeline, the first part (the engine) must be deepened and firstly prototyped.

[lippo97]

Up to now, January the 13th, @francescogorini and I have a working solution of the lexer and the parser.

I will list a summary of what we've done:

In 072fdc8 we used an algebraic data type in order to create a model of the Prolog clauses, using a TDD approach. Then we experimented with some of the scala features and we came up with a DSL that allows the creation of some Prolog clauses, using a Prolog-like syntax.

In 73d38fb we decided we no longer needed a Lexer that could fail as that should never happen in our application. We then wrote the tests that we used as a specification in order to implement a SimpleLexer.

In dbf7a13 we imported tuProlog 3.3.0. After messing around with it, we decided it was better for us to wrap its Java API in a Scala layer, focusing on preventing side-effects.
We came up with an Engine trait. It represents a generic Prolog engine and we wrote an implementation using tuProlog, called TuPrologEngine.

In 5641e7b, using a TDD approach, we wrote a Parser implementation, called PrologParser, that uses an Engine in order to parse its input.

As of ca2d7fb, almost all the code we wrote is documented.

[maldins46]

Amazing! Submit the pull request if you think the basic structure for your part is ready. We can evaluate it together at the end of the Sprint, or earlier.

[lippo97]

As of 6092804 all code we wrote is fully documented.

We completed the implementation of our library for the manipulation of Prolog programs. It includes only functions for our needs. For simplicity purposes and to refer to it we called it Scalog. We then moved it in a dedicated package.

We refactored the Engine structure: now everything concerning tuProlog lives in a dedicated package.

If you all agree, @francescogorini and I think this task can be considered as done.