So, because all the Prolog papers I was reviewing were referencing Programming in Prolog by W. F. Clocksin and C. S. Mellish I bought an older (and cheap) edition to re-read. I was surprised how good the book is for learning to program in Prolog.

You can use the wonderful Learn Prolog Now! as a free introduction text, but Clocksin and Mellish chapters on grammar rules, debugging and laying out programs makes the book priceless.

And if you want to use prolog for ‘practical matters’ I strongly recommend Jan Wielemaker Ph. D. disertation: Logic programming for knowledge-intensive interactive applications. You’ll find a good overview about using Prolog outside the logic course: Web, multi-threaded, RDFs, literate programming, interfacing with object-oriented systems and interfacing with C for creating data storages.

Finally, If you come from the functional programming world, download Scrap Your Boilerplate—Prologically! a Prolog version of the Scrap Your Boilerplate set of papers. It is a great addition for learning Prolog if your background is functional.

I’ve been getting back to knowledge based applications again and again and Jan’s thesys looks good enough to invest some time reading the 257 pdf file. 

Additionally, the swi-prolog site has an interesting page with some additional publications.

Basically code reuse and inheritance are not orthogonal, so I never know if my class hierarchy should be designed to maximize code reuse, or if I should limit my code reuse not to interfere with the class hierarchy. There’s no simple rule, and it isn’t trivial to make the right decision. As the paper summarizes:

[...]multiple inheritance uses the notion of a class in two competing roles: the generator of instances and the unit of code reuse

Schärli, Ducasse, Nierstrasz and Black describe the pitfalls of inheritance (single, multiple and through mixins) as a code reuse tool in their paper (check chapter 2) with such clarity I recommend any OOP programmer to read the paper.

Unfortunately they do not consider delegation in the mix, so there is some room for improvement. Their only reference is at the end of chapter 7:

Delegation (also known as “object-based inheritance”) is another form of composition that side-steps many of the problems related to class-based inheritance [24]

Have in mind this paper is not about reusability problems with inheritance, but about traits, their proposed solution to these problems. If you’re interested in traits you’ll find a good discussion in Reddit’s thread OO Programming: why “traits” rule and mixins and multiple inheritance suck.

Reading an old paper about dynamic creation of lexical analysers (lexers) I discovered an interesting use for lazy evaluation: Manuel M. T. Chakravarty writes a paper about lexer creation using combinators. He’s trying to obtain more flexibility by sidestepping the table-driven analysers used in static lexers and parsers.

He transforms the state table to a directed graph he builds lazily as the lexer reads the input. Using the laziness provided by the language he’s able to evaluate each part of the graph only once without keeping any overhead of what has already been evaluated.

This technique is a practical example of the usefulness of lazy evaluation, as he concludes:

non-strictness allows to significantly optimise the implementation of recursive combinators by exploiting cyclic structures. Furthermore, the lazy construction of the state transition graph minimises start-up costs when the input does not use all regular expressions of the lexical specification.

For the more bench mark oriented people, his results are pretty good. The handcoded lexer needs about 70% of the execution time of his dinamyc lexer.