Hacker News Reader

Comment by profquail | Hacker News Reader

One interesting application of Prolog I've read about is using the language to implement build systems a la make and CMake.

Most (all?) of the build systems out there today (make, CMake, rake, etc.) are declarative but they lack Prolog's inference capabilities. This gives a specific advantage -- it allows you to reduce fragility of your build system by making it dead simple to tell when you've combined incompatible configuration options (e.g., compiler flags) which you might otherwise discover halfway through a long build.

For a quick overview, check out the paper prom: A flexible, Prolog-based make tool[1].

[1]: http://www.cs.vu.nl/~kielmann/papers/THD-SP-1991-04.pdf

View on HN

I'd been thinking about just this recently. But to my mind, you don't even have to implement a build system - prolog can be directly used as one (modulo some library functions). You specify a goal, and a bunch of rules that have build-related side-effects, and then building a "target" is just a query. The syntax is even pretty similar to make, minus all the inexhaustible and unintuitive intricacies.

Two things that you'd get, that to the best of my (limited) knowledge aren't possible in make, is having cut, and the notion of both "and" and "or" - not only can you declare multiple dependencies and rules, but also "alternative" rules in case one does not succeed (e.g., in case you shell-out to a non-existent binary, try a different one).

But then you would manually have to create a list of incompatible flags. There's no way Prolog can know which gcc flags mess with your program.

Correct. It could be broken down into two parts though:

* One database containing facts about which GCC flags are incompatible with one another (i.e., cases where you can't specify both --foo and --bar). This would ideally be provided as part of the build system itself, since it's not going to change for every program built with the system.

* A small database (if one is even needed) you'd specify in your build scripts where you can enumerate specific flags or compiler features you know shouldn't be used with your program. This would augment the database provided by the build system for your specific compiler.

Note, I'm not suggesting that using Prolog to define a build system would make it impossible to specify bad or incompatible compiler flags. I am suggesting that deriving the set of flags to use for a build based on known facts about the compiler being used and your program makes it much less likely that a change you make to a build script causes the build to break in subtle ways once you've started compiling (or worse, at run-time). With Prolog, it'd be easier to detect such issues up-front so you can fix them before you start compiling or deploying.

Reply on news.ycombinator.com