Although the roots of Prova lie in logic programming (LP), the similarity can be deceptive, so the Reader will need to keep an open mind and accept that syntactic structures familiar from LP, are given additional semantics and can do much more than in a typical Prolog-like language.
The syntactic simplicity of the language is entirely intentional and motivated by the idea that simple syntax is easier to comprehend and most importantly, easier to scale up and back down, with new syntactic refinements easily available via linear code changes as opposed to complicated refactoring. The ideal here is that of a developer thinking about a new functionality and adding it incrementally, with minimal changes to the existing code. The language is thus far closer to scripting languages that foster quick experimentation and yet, in the best examples, like Ruby, yield high-quality executable systems.
The following diagram captures the main language elements.
At the top level, Prova offers three basic syntactic structures for putting together a rulebase:
- rules,
- facts (rules with no body),
- goals (rules with no head).
These are built at the elemental level from
- atomic terms,
- compound terms (lists).
Let us talk about them in a bottom-up fashion.
Simple (atomic) terms
Prova includes two types of simple terms: constants and variables. Internally, they are Java interfaces ProvaConstant and ProvaVariable, respectively.
Variables
Prova variables are essentially hollow pointers that are yet to be given some value assignment. Once the value is assigned, the variable becomes a constant term, that is a data wrapper around a Java object. Once a constant is assigned, in a typical logic and functional programming way, it cannot be assigned some other data. However, if a failure (inability to prove a new sub-goal) is detected during the goal evaluation, backtracking may result in alterantive branching, and therefore, alternative assignments to variables. Assignment of values to variables ultimately is the main point of running a Prova rulebase, i.e., providing answers to questions (goals) that are being asked.
As opposed to typical Prolog systems, variables can be typed (see the discussion in Calling Java from Prova rulebases). Previous versions of Prova also allowed variables to be typed using OWL ontologies. This feature is not available in Prova 3.0 but will return in the next version.
Syntactically, as common in Prolog, variables are represented by tokens starting with a capital letter, in the case of typed variables, prefixed by fully qualified package and class name of the corresponding Java class. It is also possible to use anonymous variables that begin with the underscore character. Some examples of Prova variables follow.
Constants
Constants may include numeric data using the Java syntax, strings in single or double quotes, as well as fully qualified static or instance fields in Java objects. Single word strings that begin with lower-case letter are for all purposes the same as such strings in quotes.
It is important to understand that during the execution of a Prova rulebase, variables get assigned values essentially becoming constants. In this case, however, these variables are syntactically represented as variables, yet for all purposes, behave like constants. For example, going slightly beyond the scope of this sub-section, this assignment sets the variable to a constant, and subsequent re-assignment of the same variable fails.
Special global constants have names starting with '$' as below.
Compound terms (lists)
Compound terms are in Prova represented as generic Prova lists. This lends itself well to agent programming as any information can be easily distributed with agents sending each other Prova lists. Critically, and uniquely different from typical LP languages, Prova keeps lists in arrays instead of recursive lists.
Lists are represented in a standard Prolog way as
Here Head is one or more (comma-separated) elements that are the list's starting (prefix) elements. The Rest is the list tail, that most often is just a variable that will match against the remainder of the list. The vertical bar is then the same as the cons operator in functional languages. Lists are an invaluable tool for pattern matching, so that we can say, we want those elements to be there in the list and unification, which is the core operation in Prova, will match the lists and assign values to free variables as appropriate.
Facts
A Prova fact is essentially a relation tuple (a record) with its elements being any term, be it constant, variable, or a (possibly recursive) list. This is different from standard Prolog, where facts normally cannot have variables. Moreover, facts can have embedded Java objects, or even global constants. Facts have the following format.
It is often the case that there are more than one fact for a given predicate symbol.
Rules
Prova rules typically are Horn rules that are first-order disjunctions of literals with exactly one positive literal. In logics, such Horn rules are known as definite clauses. The word typically highlights the fact that in Prova, global reaction rules look exactly like Prova rules (with head literal for predicate symbol rcvMsg) but their semantics are more aligned with reactive rules rather than derivation rules.
Rules are written in the standard Prolog like way. Where ':-' is pronounced as IF.