Sunday, January 07, 2024

dbProlog resurrected

I finally finished entering the text of all my blogs into my blog manager program, as I proposed to do six and a half months ago! It's not that it was difficult to do this; some days I would remember to enter 30 blogs and some days I would just forget. Anyway, having done so has given me the chance to reconnect with some historic blogs.

For some reason, I was considering the 'db Prolog' program that I wrote about almost 13 years ago! I thought that I could use the 'temp table' technique that I documented here to store the values of variables used in a rule. Maybe this will work, but I think that it will be easier to use a string table consisting of values such as '17=abraham'. I'll explain the 17 in a minute. 

Before I could get to solving rules though, I would first need to store them somehow. The original blog left this to be done in the future. When I write 'rules', I mean statements like 

father (X, Y):- male (X), parent (X, Y).
This means that someone (represented by X) is the father of someone else (represented by Y) if that someone is male and that the someone is a parent of the other person. After considering this, I decided to take an SQL approach to this and store the rule in three separate tables: one table contains an id, the arity (number of variables) in the rule and the name of the rule, i.e. 3, 2, father. The second table contains parameters of this rule, one tuple for X and one tuple for Y. Doing so allows me to assign to these parameters actual values (e.g. 17 and 18). The third table contains the clauses of the rule, along with the parameters; in the above case, there are three tuples - one with a pointer to the 'male' table and parameter 17, and two with a pointer to the 'parent' table, one with parameter 17 and one with parameter 18. Parsing the above rule into the tables was surprisingly difficult, although I admit that I was using an ad hoc approach with little preparatory thinking.

I also added a 'listing' command to the program so that I could see the entire database, both facts and rules, in one dialog. This also was fairly complicated as it requires turning several what might termed 'vertical' data (i.e. tuples in tables) into one 'horizontal' datum. Some of the ideas here might be useful when I get to actually solving a query using a rule.

Prolog is very strong on backtracking; using linked lists, this is normally achieved by means of a recursive subroutines, so turning this into a series of SQL statements is going to be awkward. Normally an SQL query will return several results, but backtracking will probably require that only one result be returned at a time. Let's say that I have the following database
male (abraham). male (isaac). female (sarah). parent (abraham, isaac). parent (sarah, isaac). father (X, Y):- male (X), parent (X, Y).
When the query ? father (X, Y) is issued, a Prolog interpreter will first try to solve the subquery male (X); there are two such lines. Using the first line, male (X) will succeed with X being bound to the value 'abraham' (this is where the temp table may come in use). Then the query parent (X, Y) has to be solved, but as X is abraham, it becomes parent (abraham, Y); this is solved by the fourth line. Prolog will then restart the query, where male (X) will match male (isaac). But there is no line matching parent (isaac, Y), so this time the query will fail. I'm not saying that this is easy to achieve with a recursive subroutine but it's probably easier than working with SQL. The backtracking would be clearer if the order of the first two lines were reversed.

I shall have to brush up on the Firebird dialect of SQL to find how I can retrive only the second tuple in a table (i.e. retrieve one tuple starting with tuple 2). This isn't something that I regularly do so I don't recall the syntax required.



On another topic, I see that automatic emails were sent for the last two blogs, even though they contained pictures, so the hypothesis that emails are sent only for blogs with no pictures has been disproved. This behaviour doesn't appear to be consistent.



This day in history:

Blog #Date TitleTags
53007/01/2013Recurring actors in long running TV showsTV series
91007/01/2016Vinyl log 25 - 3 JanuaryVinyl log, Jackson Browne
100007/01/20171000 blog entriesMeta-blogging
136907/01/2021I haven't disappearedDBA, Health
145607/01/2022Fourth time aroundCovid-19
157207/01/2023PassportsPersonal

No comments: