QuLog is a higher-order logic/functional/string processing language with an imperative rule language sitting on top, defining actions. QuLog’s action rules are used to program multi-threaded communicating agent behaviour. Its declarative subset is used for the agent’s belief store. The language is flexibly typed and allows a combination of compile time and run-time type checking.
It is a fully integrated language in that function calls can appear as or inside arguments to relation calls, and relational queries can be used as guards of function rules. It has sets as a separate data type from lists with set <-> list convertors. Both can be created using Trm::Query comprehension expressions.
Sets are manipulated using union, intersection and difference operators. Lists are manipulated as in Prolog but also using non-deterministic pattern matching. Similar pattern matching is used for string processing as a precursor to DCG parsing. An ’in’ primitive can be used to access elements of sets, lists and characters in strings.
QuLog supports type safe meta-level programming to complement its type safe higher order programming. However there are no lambda expressions in QuLog. All code has to be named and defined in the top level sequence of type definitions, type declarations and relation, function and action defining rules. At this time QuLog has no module system, so each consulted file must use different type and code names for its definitions.
As mentioned above, using its action rules and action primitives multi-threaded message communicating agent applications can be created with the agents communicating using the companion Pedro publish/subscribe and destination addressed communications server. Such an agent application can also receive and send MQTT notifications routed via an MQTT publish/subscribe server.
Debugging is done by putting a
watch on any number of relations, functions and actions. This invisibly transforms their code to display each call, the input and output bindings of the unification or match of the call with each rule that can be used, and optiionally the instantiated body of the rule
before it is used. An
unwatch command reverses the code transformation.
This manual assumes familiarity with logic programming and with higher functional programming in a typed language. A tutorial introduction to the QuLog declarative subset is given in,
A formal systax using extended BNF grammar rules is given as an Appendix of this manual.
examples/introduction/qlexamples.qlg is an example QuLog program that can be consulted and queried.
teleor extension of the QuLog interpreter allows program files to be consulted containing TeleoR procedures as well as QuLog rules. This extension includes a generic agent shell that can be launched to execute calls to TeleoR procedures as tasks. It can be configured by including specially named QuLog action procedures and relations in your program file, as explained in
To support use of TeleoR robotic agent programs with robots and simulations that use ROS, there is an example Python program in the ROS directory that will act as an interface between our Pedro inter-agent and inter-process communications server and an invocation of ROS. This program and information on how to modify it
for a particular ROS architecture, are in the
examples/ROS directory of the QuLog distribution.
QuLog has some predefined constructor types. These usually have a name such as
write_type__ and their constructors and atom values often end with underscore, for example the constructor
q_ and the atom
nl_ of the
write_type__ system type. We recommend you do not use a trailing underscore in any of your own type definitions. If you do use a system reserved name the compiler will reject your definition giving an error message.
Every data type of QuLog has a place in a lattice of types. At the bottom of the lattice is the system type
bottom with one data value
botton_, meaning undefined. At the top is the system type
top. There are no values that just belong to
top but it includes all data and code types. Just below
top on the data side of the lattice is the type
term, which will be familiar to Prolog programmers. All other data types are sub-types of
code is the other immediate sub-type of top. All relation, function, action and TeleoR procedure types are sub-types of
For a particular program the lattice of system and program associated types is finite.