Logic Programming

[akbooer]

It's highly likely that you're not on every-day speaking terms with Prolog.

According to the renowned TIOBE popularity index Prolog stands today (March 2023) at 0.23% (#39) – for perspective, Python (#1) is at 14.83%, Lua (#30) is at 0.36%.

...so a micro-tutorial may be in order.

Prolog's universe is a database of facts and rules.

Facts:

small(lua).
powerful(lua).
powerful(python).
large(python).

meaning whatever you want it to mean, but let's say that it's true that lua is small and it's also true that it's powerful. On the other hand, python is powerful and large.

Rules:

great_to_use(X) :- small(X), powerful(X).

meaning that X is great to use if it's small and also powerful. Note that X is a variable because it starts with an upper-case letter.

Prolog's syntax is minimal and concise, and can take some getting used to. It has atoms (like lua), variables (like X), lists ([a,b,c]), strings "hello", and numbers 1.23. The things that look like procedure calls are predicates, and their arguments can be any other language construct. They can also succeed multiple times, returning different solutions.

Using the above database of facts and rules, we can ask which languages are powerful:

?- powerful(X).

and receive the result(s):

powerful(lua).
powerful(python).

but we can also ask which languages are great to use, which invokes a rule acting on some of the database facts:

?- great_to_use(X).

giving, of course:

great_to_use(lua).

Now just imagine how you can use rules like this when the facts in the database are the state of your HA devices...

[LibraSun]

Shocked to find FORTAN occupying the #17 slot! And there's Groovy down at #34.

[akbooer]

Prolog rules can be applied to a live database of facts which reflect the state of your SmartHome and make a powerful combination.

The first two predicates I've integrated into my openLuup Prolog prototype are:

• luup_var (Device, Service, Variable, Value) and
• luup_attr (Device, Attribute, Value)

These mirror the standard Luup calls luup.variable_get() and luup.attr_get(), and, at first glance, provide the same functionality. Querying a variable:

?- luup_var(2,"openLuup","Memory_Mb",X).

yields the result:

luup_var(2,"openLuup","Memory_Mb",4.3).

And similarly for a device attribute:

?- luup_attr(2,"room", X).

gives:

luup_attr(2,"room", 0)

All very much as expected. But what happens when an unknown (a Prolog variable) is put in place of one of the usual 'input' parameters?

?- luup_var(2,"openLuup",V, X).

Well, of course, you get all the possible solutions which match:

luup_var(2,"openLuup","StartTime","2023-03-11T16:44:00").
luup_var(2,"openLuup","Vnumber",230303).
luup_var(2,"openLuup","Uptime_Days",0.03).
luup_var(2,"openLuup","CpuLoad",0.1).
luup_var(2,"openLuup","Memory_Mb",7.1).
luup_var(2,"openLuup","Version","v23.3.3").
luup_var(2,"openLuup","HouseMode",1).

Here's an example of asking for which devices have been disabled:

?- luup_attr(D,"disabled", 1).

and we discover that there are two of them:

luup_attr(371,"disabled",1).
luup_attr(349,"disabled",1).

You could, if you must, also ask for the value of all variables in the system:

?- luup_var(D,S,V, X).

This screenshot of the console:

...captures the beginning of the output, and shows that there are 466 variables in my test system.

This only just scratches the surface of what is possible, and next post I'll show some slightly more sophisticated (and useful) examples.

[akbooer]

One of the joys of the Prolog language is the conciseness. You simply express the solution you are after as a series of assertions which must be true. There are no explicit variable declarations, for-loops, if-then-else statements, or begin-end blocks.

Let's choose a simple, but realistic, example using the Luup primitives and answer the question: which devices are battery powered?

luup_var(D,S,"BatteryLevel",Value)

which, for my test system gives:

luup_var(352,"urn:micasaverde-com:serviceId:HaDevice1","BatteryLevel",12)
luup_var(353,"urn:micasaverde-com:serviceId:HaDevice1","BatteryLevel",19)
luup_var(370,"urn:micasaverde-com:serviceId:HaDevice1","BatteryLevel",77)
luup_var(351,"urn:micasaverde-com:serviceId:HaDevice1","BatteryLevel",100)
luup_var(30004,"urn:micasaverde-com:serviceId:HaDevice1","BatteryLevel",97)

By default, the user interface returns the results in the same form as the query itself. There is, however, the option to format the results as an arbitrary Prolog term, using the variables from the original query.

So, asking the same question, but only wanting the device number and battery level as a result:

Gives this result:

[352,12]
[353,19]
[370,77]
[351,100]
[30004,97]

A bit cryptic for you? Let's retrieve the device name too, and also say we're only interested in batteries which are under 20% full. Using a pattern of [D, Name, Value] and this query:

luup_var(D,S,"BatteryLevel",Value), Value < 20, luup_attr(D, "name", Name)

we get:

[352,"Hue Hue motion sensor 1",12]
[353,"Hue Hue ambient light sensor 1",19]

...very suitable output to trigger an alert email message, for example.

This is significantly briefer than any Lua code that you could write to achieve the same result. Up to this point, through, we're just using it as a database query language, but Prolog is capable of significantly more complex logical inferences...

[mrFarmer]

Now this is a flashback to University. They tried to teach us logical and AI programming using prolog. I might still have a book on it, you know one of those things made out many sheets of paper
And we used Fortran for mathematical problems I thought those professors where dinosaurs back then. Lol, how slow that world changes in our fast changing world.

[akbooer]

@mrFarmer said in Logic Programming:

I might still have a book on it, you know one of those things made out many sheets of paper

Ah! This one, perhaps?

Programming in Prolog

or this

SupaduDev

The Art of Prolog

This new edition of The Art of Prolog contains a number of important changes. Most background sections at the end of each chapter have been updated to take a...

...both old favourites.

By its very nature, logic programming has very robust theoretical foundations and, although not widely used in its basic form, it did give rise to constraint-based programming (Ciao, for example), which is applied to almost everything you can think of these days.

[a-lurker]

@akbooer a few months back, you hinted in post somewhere (can't find it), that you were working on a "new project"! It will be interesting to see how this works out.

In the openLuup realm you already have a large database of "Facts" that you can "Query" and apply "Rules" to - so off to a good start from that aspect. (don't quote me on the nomenclature).

The book referenced above can be downloaded from here: The Art of Prolog along with many other relevant texts.

This one is also a favorite - it can be downloaded but I don't have an account and I already have a physical copy (might be worth a few bucks on ebay). May be someone else could download the pdf and post it here? Not the latest Prolog but interesting all the same. The Borland people had some great products in the old days.

@mrFarmer said: flashback to University... you know one of those things made out many sheets of paper.

Yeah - you knew you were getting the latest stuff when it was a pile of photostats stapled together.

[a-lurker]

Any more work on this one - I'm sure University of North Texas. USA would be interested in your work? Eg as a teaching aid?

Mainstream IoT users or other parties may find, out of ignorance, that Prolog is a bit on the esoteric side - there is no doubt others would be interested?

Lua, in itself, was born under interesting circumstances (politics) and is now seen in many a device. Anyone got a FritzBox for example? Let alone the game industry.

Prolog is not a language I am familiar with but I also absolutely refused to learn Fortran - just one GO TO to many and let's not speak of the pre declaration of i, j, k .. etc. Almost assembly language. So easy to make a Fortran compiler - not surprising Fortran was all over the place.

At that point, I got regimented to using parallel C for a few weeks. Thought that was a back step but it certainly wasn't. I now write Lua like it was C - just habit and I wasn't that good at C.

[akbooer]

Well, it went as far as I needed at the time, and then I went down a rabbit hole of some esoteric (and sometimes quite old) Prolog research papers.

I learned Fortran IV at school, and much later ran industrial research groups whose lingua franca was Fortran. Yes, easy enough to make a small compiler (although it’s worth looking at the early compilers’ treatment of arithmetic operator priorities!)

I’ve always thought of C as an assembly language (based on PDP 11 instructions) and always eschewed it.

Lua is almost perfection, but if you’re wanting straight-forward logical inference, then use a proper logic language! I think the examples I gave shows some of the advantages.

[akbooer]

Just for fun, I checked the latest TIOBE index:

#11 Fortran 1.4%
#24 Prolog 0.77%
#33 Lua 0.44%

[a-lurker]

Arhhh just fashion - this language; that language - surely they all mostly have If then else or For loops in some form or a greater than test.

I did a lot of assembly language (poorly) and DSP (poorly) and main stream language programmers could not understand I new nothing about high level languages. Lots of stuffing around with moving stuff from the accumulator to some register. The 68000 Motorola orthogonality was a dream come true compared to the Intel stuff. I still have nighmares thinking about the Intel addressing modes.

If I remember correctly (unlikely) the Fairchild F8 reset the Accumulator command to zero was 70 hex.

Whoops I tripped and the punched cards went all over the place. I digress.

[a-lurker]

@akbooer

On the Lua sides of things - have a look at this GitHub blog and this chart about half way down the page. Lua has its supporters.

[akbooer]

That’s a really interesting read – thanks!