Comment by RBerenguel | Hacker News Reader

Comment by RBerenguel | Hacker News Reader

I find Prolog a marvel in "look what I can do!" Writing stupidly fun code in it is almost a no-brainer, compared to other languages (I have a half-assed English grammar parser in 60-odd lines, with a few comments!) But getting into prolog needs a complete rewire of how you think about programming: if you are used to imperative (or functional, or list-based, or almost whatever else) prolog feels very foreign.

I'm also a Lisp aficionado, having written more than a few small pieces (not counting emacs lisp, where I write more than a few!) to scrape the web or draw Lavaurs chords.

And my day-to-day I write PHP, Python, awk, R and whatever it takes to improve revenues in my company. So I have both perspectives, Lisp & Prolog and its awesomeness and "the other side." And mixing them up (splurge into data with awk, write it as Prolog terms, analyse its structure in Prolog and represent it in R) is one of the biggest joys of programming. Don't get entrenched in your "language," learn as many as you can and cherry-pick each one as you see fit for the problem.

Indeed! During a security assessment of a large code base, I wrote a simple ruby source code parser that spat out Prolog terms. After that, it was a breeze to find certain kinds of logic errors, such as code paths that used user input before sanitation...

It's beautiful when it all works together, checking everything manually would certainly have been a PITA and would have resulted in a lower quality result.

Definitely an aha moment!

Could you open source it? I'm very interested in seeing how one would do that, I've been thinking about writing one myself, for PHP (I've a somewhat large codebase to inherit, that only works in a old version of PHP, and I might need to migrate it).

I don't have the IP for the code so I can't copy it here, but what I did was very simple and the gist of it is described below:

The parser used regular expressions to recognise function definitions and calls in those definitions. I used file names as the function scope, this was good enough because there were no two functions with identical names in the same file. Function calls became the following terms: "calls(x,y,z).", meaning that function x in file y calls z.

These "calls" terms actually define a directed graph. If you google "prolog path through directed graph", there are lots of hits that will help you out. The following (untested) code should get you started:

    %there is a path if there is a call
    path(Caller, File, Called, [calls(Caller, File, Called)]) :- calls(Caller, File, Called). 
    %there is a path if there is a call to some function and there is a path from that function
    path(Caller, File, Called, [calls(Caller, File, A) | P]) :- calls(Caller, File, A), path(A, _, Called).

After that, you can find all possible paths with "findall/3" and check for existence of a certain known good/bad function with "member/2" (again, google is your friend)

Due to some properties of the code, this simple approach worked well enough for me. Hopefully this helps you out.

Probably needs a green cut in the first term... Or maybe not. I'm quite backtracking-puzzled about green cuts in generic terms I write, so thinking about them in others' code is even more puzzling :)

Every time I use prolog for something (or more like I think "Ha! This is meat for Prolog!") I feel like I'm just using an awesomely sharp knife. As I like to put it, it's like a database on steroids.

A few months ago I was "bored" and decided to write a "scrapper" (kind of) to get all my tweets (this was before twitter opened tweets for download). It was relatively easy: write a little javascript that scrolls to bottom and then regex-matches all the (correctly loaded now) tweet data in the webpage. Then collect the tweet text in a plain ol' list that then is dumped on-screen as prolog terms... and saved as plain text.

With this simple thing I could make interesting queries (who I mention more often, when I'm more prone to tweet...) in a breeze, and I could made even better queries with a little more work/available data.

Back when I was at the university, Prolog and Lisp were the forbiden languages to write compilers on our compiler courses, because the teachers saw them as making the whole exercise too easy.

You should have written a tiny Lisp in whatever language they did allow and then go from there.

We got to use Java with JavaCC, this was back in 1998 and everyone wanted to use it, sounds familiar?

From PAIP Chapter 11 on -- funny enough, logic programming:

"A language that doesn't affect the way you think about programming is not worth knowing." -Alan Perlis

Reply on news.ycombinator.com