wiki.visual-prolog.com - User contributions [en]

Fundamental Visual Prolog

2014-03-23T19:42:25Z

Taras.evt: The code states, that the file is in the directory, which is one level up from execution path. The executable is in "\Exe\", therefore fa.txt should be in the root of project (alongside of main.pro).

{{FundamentalPrologNavbar}}

In this tutorial, we will introduce a program that is developed on the Visual Prolog platform. The essential algorithms of the tutorial are the same as those that were developed in the tutorial [[Fundamental Prolog Part 2]].

==Differences in Visual Prolog and Traditional Prolog==

The differences between traditional Prolog and Visual Prolog can be broadly divided into these categories:

*Program structure differences: There are distinct, yet easy to understand differences between the structure used in traditional Prolog and that used in Visual Prolog. It essentially comprises of understanding how to mark out the declarations from the definitions, and to indicate the main ''Goal'' that the program has to seek using specific keywords.

*File considerations: Visual Prolog gives various facilities to organize the structure of the program into different kinds of files.

*Scope access issues: A Visual Prolog program can pick up functionality developed in other modules using a concept called ''scope identification''.

*Object orientation: A Visual Prolog program can be written as an object-oriented program, using classic object oriented features.

===Program Structure Differences===

====Declarations and Definitions====

In Prolog, when we need to use a predicate we simply do so without any prior intimation to the Prolog engine about our intention. For example; in the earlier tutorial the grandFather predicate's clause was directly written down using the traditional Prolog's predicate head and body construction. We did not bother to inform the engine explicitly in the code that such a predicate construction is to be expected later.

Similarly, when a compound domain is to be used in traditional Prolog, we can use it without first forewarning the Prolog engine about our intention to use the domain. We simply use a domain, the moment we feel the need for it.

However, in Visual Prolog, before writing down the code for the clause body of a predicate, we would first need to declare the existence of such a predicate to the compiler. Similarly, before using any domains, they need to be declared and their presence is to be informed to the compiler.

The reason such forewarnings are required in Visual Prolog is essentially to ensure that runtime exceptions are converted into compile time errors as far as possible.

By ''"runtime exceptions"'', we mean the issues that turn up only at the time of running the program that were compiled with it. For example, if you had intended to use an integer as the argument of a functor, and instead of the integer you had erroneously used a real number, it would become a ''runtime'' error (in programs written using most other compilers, but not Visual Prolog) and the program would fail there.

When you also declare the predicates and domains that are defined, such kind of positional grammar (which argument belongs to which domain), etc. is made available to the compiler. Therefore, when Visual Prolog performs a compilation, it checks the program quite thoroughly to weed out such grammatical and other mistakes.

Because of this feature in Visual Prolog, the overall efficiency of a programmer improves. The programmer does not have to wait till the program is actually executed to detect a bug. In fact, those of you, who are experienced in programming, would understand what a life-saver this can be; for often, the particular sequence of events that is causing a ''runtime exception'' to happen at run-time may be so elusive that the bug may actually turn up after several years, or it may manifest itself in some crucially critical or other embarrassing situations!

All this automatically implies that the compiler '''has''' to be given explicit instructions regarding the predicates and domains that exist in the code using appropriate declarations before the same are defined.

====Keywords====

A Visual Prolog program consists of Prolog code which is punctuated into different '''sections''' by appropriate keywords that inform the compiler the code it has to generate. For example, there are keywords that differentiate the ''declarations'' from the ''definitions'' of predicates and domains. Usually, each section is preceded by a keyword. There is normally no keyword which signifies the ending of a particular section. The presence of another keyword indicates the ending of the previous section, and the starting of the next one.

The exception to this rule, are the keywords "implement" and "end implement" The code contained between these two keywords indicates the code to be used for a particular class. Those of you who do not understand the concept of a "class" can, for now (i.e. in this tutorial), think of it as a module or a section of the overall program code.

For the purpose of this tutorial, we'll introduce only the following keywords (given below). We are also giving the purpose behind these keywords, and the actual syntax can be easily learnt from the documentation. There are other keywords also in Visual Prolog, and those can easily be picked up in later tutorials and the documentation.

The list of the keywords that you need to know in this tutorial is the following:

'''implement''' and '''end implement'''

:Among all the keywords discussed here, this is the only one, which exists as a pair. Visual Prolog treats the code written between these two keywords as the code that belongs to one class. The name of the class MUST be given after the implement keyword.

'''open'''

:This keyword is used to extend the ''scope visibility'' of the class. It is to be used just after the implement keyword.

'''constants'''

:This keyword is used to mark a section of the code that defines some commonly used values in the program code. For example, if the string literal "PDC Prolog" is to be used in multiple locations throughout the code, then you can define a mnemonic (a short-form, easily remembered word) for the same thus:

<blockquote><vip>constants
pdc = "PDC Prolog".</vip></blockquote>

:Note that the definition of a constant ends in a period (.). Unlike a Prolog variable, a constant should be a word starting with a lower case letter.

'''domains'''

:This keyword is used to mark a section declaring the domains that would be used in the code. There are many variations for the syntax of such domain declarations, and they cater to the all the possible kinds of domains that would be used later on in the code. As this tutorial is a basic one, we shall not get into the finer details of the domain declarations that can be possible.

:To summarize here, you would be declaring the functor that would be used for the domain and the kind of domains that would form its arguments. Functors and compound domains were explained in detail in the previous part of the Tutorial.

'''class facts'''

:This keyword designates a section, which declares the facts that would be used later on in the code of the program. Each fact is declared with the name used to signify the fact and the arguments that are used for the respective facts along with the domains that those arguments belong to.

'''class predicates'''

:This section contains the declarations of the predicates that would be later defined in the clauses section of the code. Once again, the names that would be used for these predicates along with the arguments and the domains, to which the arguments belong to, would be indicated in this section.

'''clauses'''

:Of all the sections that are present in a Visual Prolog code, this section is the one that closely mimics a traditional Prolog program. It contains the actual ''definitions'' of the previously declared predicates. And you would find that the predicates used here would follow the syntax as declared in the ''class predicates'' section.

'''goal'''

:This section defines the main entry point into a Visual Prolog program. A more detailed explanation is given below.

====Goal====

In traditional Prolog, whenever a predicate is defined in the code, the Prolog Engine can be instructed to start the code execution from that predicate onwards. However, that is not the case with Visual Prolog. Being a ''compiler'' it has the responsibility of producing efficiently executing code for the program you write. This code would not be actually executing at the same time the ''compiler'' is doing its work. Hence, the ''compiler'' needs to know beforehand the exact predicate from which the code execution would start, so that later on when the program is called to perform, it can do so from the correct starting point. As you may have guessed, the compiled program can run independently without the Visual Prolog compiler or the IDE itself.

In order to do that, there is a special section indicated by the keyword ''Goal''. Think of it as a special predicate that you would write without arguments. That predicate is the one from which the entire program execution will start.

===File Considerations===

Many times, it may become cumbersome to put all the parts of the program into one file itself. It may even make the program unreadable and sometimes incorrect. Visual Prolog has the capability of dividing the program code into separate files using the IDE (Integrated Development Environment) and it is possible to write neat pieces of code into separate files using that IDE. When it is done in that manner, things that are to be used commonly can be accessed across files. E.g. If you have a domain that is to be used in multiple files, then the declaration of that domain is done in a separate file, and that file is then accessed from other files.

However, for the purpose of simplifying this particular tutorial, we shall predominantly be using only one file to develop the program code. In the course of constructing the program, the IDE would automatically create some more files which we can ignore for the time being. We can learn about them in future tutorials.

===Scope Access Issues===

Visual Prolog divides the total program code into separate parts, each part defining one class. In object oriented languages, a class is a package of code and its associated data which is put together. This requires more explanation which would be available in later tutorials. As noted earlier, for those of you who are not familiar with object oriented programs, you can think of a ''class'' loosely as being synonymous to ''modules''. Normally, Visual Prolog defines each class in its own separate file.

During the program execution, it often so happens that the program may need to invoke a predicate that is actually defined in another class (file). Similarly, data (constants) or domains defined in a class may need to be accessed from a different file.

Visual Prolog allows such cross class code/data references using a concept called scope access. This can be understood by an example. Suppose there is a predicate called pred1 defined in a class called class1 (which is written down in another file using the IDE), and we need to call that predicate in the clause body of some other predicate, pred2 in a different file (say class2) then this is how pred1 would be called within the clause body of pred2 :

<vip>clauses
pred3:-
...
!.

pred2:-
class1::pred1, % pred1 is not known in this class. It is defined in some other class, hence a class qualifier is needed
pred3,
...</vip>

In the above example, you can see that the clause body of pred2 calls two predicates pred1 and pred3. As pred1 is defined in another file (which defines class1), the word class1 with the token '''::''' (two colons) precedes the word pred1. This can be called as a class qualifier.But the predicate pred3 is defined within the same file as pred2 itself. Hence there is no need to indicate class2:: prior to the predicate call for pred3.

This behavior is technically explained thus: The ''scope visibility'' of pred3 is within the same scope of pred2. Hence there is no need to clarify that pred3 is from the same class as pred2. The compiler would automatically look for the definition of pred3 within the same scope area as defined for class2.

The scope area of a particular class definition is restricted to the class that is implemented in a particular file (i.e. code that is written within the implement ''-'' end implement keywords). The predicates defined therein can call each other without the class qualifier and the double colon (::) token preceding it.

The scope area of a class can be extended by using the open keyword. This keyword informs the compiler to bring in names (of predicates / constants / domains) that were defined in other files. If a scope area is extended, then we need not write the class qualifier with the double colon.

<vip>open class1
...

clauses
pred3:-
...
!.

pred2:-
pred1, %Note: "class1::" qualifier is not needed anymore, as the scope area is extended using the 'open' keyword
pred3,
...</vip>

===Object Orientation===

The current version of Visual Prolog is a strongly object oriented language. The ENTIRE code which is developed for a program is put into appropriate classes, as needed. This happens by default, even if you are not interested in the object oriented features of the language. You would notice this feature in the example given in this tutorial also. The code is inserted into a class called "family1" even though we would eventually not use any objects created from that class. Instead, we would use publicly accessible predicates of the code within that class directly.

This tutorial will not handle the object oriented features of the language. Future tutorials would extend this concept, and even actually use the object oriented features.

==A Full Fledged Example: family1.prj6==

'''Download:''' source files of the example project used in this tutorial:

* Visual Prolog 7.4 and 7.3 install examples in the IDE:
*:'''Help -> Install Examples...'''
* [http://download.pdc.dk/vip/72/tutorial_examples/fundamental_visual_prolog/family1.zip Visual Prolog 7.2 version]
* [http://download.pdc.dk/vip/71/examples/tutorial_examples/fundamental_visual_prolog/family1.zip Visual Prolog 7.1 version]

Let us now put all the knowledge we've gathered together to create our first Visual Prolog program. This will contain the same basic logic that was explored in the Tutorial "Fundamental Prolog. Part 2". All the code that is to be written for this tutorial is shown below. The actual code writing will be done using the Visual Prolog IDE (Integrated Development Environment). There are some more files that are needed for the tutorial, but those would automatically be generated and maintained by the IDE. The step by step instructions (using screenshots) for utilizing the IDE to develop the program will shortly follow.

But first of all, let us acquaint ourselves with the main code of the program:

<vip>implement main
open core

domains
gender = female(); male().

class facts - familyDB
person : (string Name, gender Gender).
parent : (string Person, string Parent).

class predicates
father : (string Person, string Father) nondeterm anyflow.
clauses
father(Person, Father) :-
parent(Person, Father),
person(Father, male()).

class predicates
grandFather : (string Person, string GrandFather) nondeterm (o,o).
clauses
grandFather(Person, GrandFather) :-
parent(Person, Parent),
father(Parent, GrandFather).

class predicates
ancestor : (string Person, string Ancestor) nondeterm (i,o).
clauses
ancestor(Person, Ancestor) :-
parent(Person, Ancestor).
ancestor(Person, Ancestor) :-
parent(Person, P1),
ancestor(P1, Ancestor).

class predicates
reconsult : (string FileName).
clauses
reconsult(FileName) :-
retractFactDB(familyDB),
file::consult(FileName, familyDB).

clauses
run():-
console::init(),
stdIO::write("Load data\n"),
reconsult("..\\fa.txt"),
stdIO::write("\nfather test\n"),
father(X, Y),
stdIO::writef("% is the father of %\n", Y, X),
fail.
run():-
stdIO::write("\ngrandFather test\n"),
grandFather(X, Y),
stdIO::writef("% is the grandfather of %\n", Y, X),
fail.
run():-
stdIO::write("\nancestor of Pam test\n"),
X = "Pam",
ancestor(X, Y),
stdIO::writef("% is the ancestor of %\n", Y, X),
fail.
run():-
stdIO::write("End of test\n").
end implement main

goal
mainExe::run(main::run).</vip>

===Step 1: Create a New Console Project in the IDE===

'''Step 1a.''' After starting the Visual Prolog IDE, click on the New menu item from the Project menu.

'''Step 1b.''' A dialog would be presented to you. Enter all the relevant information. Ensure that the Project Kind is ''Console'' and NOT ''GUI''.

:[[Image:FundamentalVisualProlog2.png]]

===Step 2: Build an Empty Project===

'''Step 2a.''' When the project is just created, the IDE would display the following project window. At this point in time, it does not have any clue about what files the project is dependent on. It does, however create the basic source code files for the project.

'''Step 2b.''' Use the Build menu item of the Build menu, to compile and link the empty project to create an executable file which basically does not do anything. (At this point it time, it would not generate any errors either)

While building the project, take a look at the messages that are dynamically displayed in the '''Messages''' window of the IDE. (In the case the '''Messages''' window is not visible, you can turn it on using the Window menu of the IDE) You will notice that the IDE intelligently pulls in ALL the necessary PFC (Prolog Foundation Classes) modules into your project. PFC classes are those classes which contains the basic functionality on which your programs would be built.

===Step 3: Populate the main.pro with the Actual Code===

'''Step 3a.''' The default code inserted by the IDE is very basic and does not do anything useful. You would need to delete the entire code and copy and paste the actual code of main.pro (given in this tutorial) into that window.

:[[Image:FundamentalVisualProlog5.png]]

'''Step 3b.''' After you perform the copy-paste operation, the main.pro window would now look as shown below:

:[[Image:FundamentalVisualProlog6.png]]

===Step 4: Rebuild the Code===

Re-invoke the Build menu command, and the IDE will notice that the source code has changed, and will take measures to appropriately recompile the correct sections. If you use the Build All menu command, then ''ALL'' the modules would be recompiled. For large programs this can consume some time. Build All is often used ONLY at the end of a series of smaller compilations; just to ensure that everything is in ship-shape order.

During the ''Build'' process, the IDE not only does the compilation; but it also determines whether the project may need any other missing PFC modules, and inserts those and re-starts the compilation process if required. This can be seen in the messages appearing in the Messages window, where you'll notice the IDE was forced to build the project ''twice'' because of some additional include statements.

:[[Image:FundamentalVisualProlog7.png]]

===Step 5: Execute the Program===

We now have our first true application complied using Visual Prolog. In order to test the application we've just compiled, you can run the program using the Build | Run ''in'' Window menu command. However, in our case this would result in an error. The reason is that our little program is trying to read a text file (fa.txt) for its functioning. That text file contains the actual data regarding persons which our program will process. We'll come to the syntax of that file a bit later.

We need to now write that text file using some text editor and place it in the same directory where the executable is now residing. Normally, the executable would reside in the sub-folder called exe from the main project folder.

Let us create such a file using the IDE itself. Use the File | New menu command. The Create Project Item window will appear. Select Text file from the list on the left hand side. Then select the appropriate directory where the file is to reside (The same directory where the project file main.pro is present). Then, give the filename ''fa.txt'' and click on the Create button of the dialog. Till the filename is given, the Create button would be grayed (disabled). Make sure that the checkbox: Add to project as module is checked on. The advantage of adding it to the project is that it would be available for any subsequent debugging, etc.

The contents of the file would be as follows:

<vip>clauses
person("Judith",female()).
person("Bill",male()).
person("John",male()).
person("Pam",female()).
parent("John","Judith").
parent("Bill","John").
parent("Pam","Bill").</vip>

Though it is a data file, you would notice that the syntax of the file is VERY similar to regular Prolog code! Even though the program is now compiled and is now in a binary format; you can change the output by simply changing the crucial data the program is processing. And that data is written into this text file using the same syntax as Prolog. Thus Visual Prolog emulates the ''dynamic'' code writing capability of traditional Prolog. Albeit, not all features are available but at least complicated domains such as those in this example can definitely be given.

The syntax used in fa.txt MUST be compatible with the domain definitions of the program. E.g. The functor used for defining a person MUST be ''person'' and not anything else; else appropriate compound domain representing that functor would not get initialized. (We had covered the topic of functors and compound domains in an earlier tutorial).

Now, when you run the program using the Build | Run in the Window menu command, this is what you'll see:

:[[Image:FundamentalVisualProlog8.png]]

The program processes the information in the file fa.txt and works out the logical sequence of the parentages of people given there.

===A Round up of the Program===

The logic of the program is very simple. We had discussed it in an earlier tutorial, where we explained how the correct representation of data can help yield the appropriate results in a Prolog program. Let us now discuss the manner in which this logic works.

At start up, the main predicate will be invoked directly. This in turns branches off to the run predicate. The first thing the run predicate will do is to read in the data which is written in the file fa.txt. Once the data is in place, the program systematically progresses from one test to another to process the data and write out the conclusions of that test onto the console.

The mechanisms for processing the data are standard mechanisms of backtracking and recursions. This tutorial is not the place for a detailed explanation of how Prolog works, but here is a short summary of the internal workings.

When the run predicate is calling the father predicate, it does not stop at the first satisfactory ending of the father predicate. The invoking of a fail at the end of the predicate, forces the Prolog engine to seek another pass through the father predicate. Such a behavior is called ''backtracking'', because the Prolog engine literally seems to backtrack over code which had earlier executed.

This happens recursively (i.e. as a repetitive process or cyclically), and at each cycle the father predicate yields the next result. Eventually all the possible definitions of "fathers" given in the data are exhausted, and the run predicate would have no choice but carry over to the next clause body of the run predicate.

The father predicate (as well as some other predicates) has been declared to be non-deterministic. The keyword nondeterm can be used to declare non-deterministic predicates; i.e. predicates that can yield multiple answers using backtracking.

If the no keyword is used in a predicate declaration, then the predicate has got the procedure mode, which can give only one solution, and the father predicate will stop after yielding the first result and cannot be re-entered into. Also, one must be careful in the usage of the cut (!) in the clause bodies of such non-deterministic predicates. If there is a cut at the end of the clause body of the father predicate, yet again; the predicate will yield only one solution (even if it has been declared to be non-deterministic).

The anyflow flow-pattern tells the compiler that the parameters that are given for the predicate could be either free or bound, with no restrictions whatsoever. That means, with the same definition of the father predicate, it would be possible to both yield the father's name (in case the name of the offspring was bound) OR the offspring's name (in case the name of the father was bound). It can also handle situations where both are bound; in which case the predicate will check if such a relationship exists in the data.

And; to state the obvious; the anyflow flow pattern can also accommodate a situation where both the parameters of the father predicate are free variables. In such a case, the father predicate will yield the various combinations of father+offspring present in the data the program has learnt (through consulting the fa.txt file) to the enquirer. The last usage is what is performed in the run predicate, as seen in the code snippet below. You would notice that the variables X and Y given to the father predicate are not bound when the father predicate is called.

<vip>clauses
run():-
console::init(),
stdIO::write("Load data\n"),
reconsult("fa.txt"),
stdIO::write("\nfather test\n"),
father(X,Y),
stdIO::writef("% is the father of %\n", Y, X),
fail.</vip>

==Conclusion==

In this lesson we learnt that programs written in Visual Prolog are often very similar to those written in traditional Prolog. There are several keywords that are used to differentiate the various parts of a Visual Prolog source code. Though Visual Prolog is an object-oriented language, it is possible to develop code which avoids the language's object-oriented features. A complete console-based application (family1) was developed in this tutorial, which explains, how to create such a program.

We also found that it is possible to emulate the dynamic working of a traditional Prolog program by keeping part of the code as a data file outside the main binary compiled application. The syntax of such a data file closely follows Prolog syntax.

==References==
[[ru:Основы Системы Visual Prolog]]
[[Category:Fundamental Visual Prolog Tutorial]]

Fundamental Prolog Part 2

2014-03-23T17:52:38Z

Taras.evt: Fix typo in code

{{FundamentalPrologNavbar}}

In this tutorial you will learn about some more fundamental ideas of Prolog programming; continuing from where we left off in the Part 1 of this tutorial (Fundamental Prolog). In this tutorial, we are going to concentrate on how data is ''modeled'' in Prolog, before we can perform actions on them. Hence, there are not much examples concerning code execution here. We are assuming that you are already familiar with the issues concerning '''execution strategy''' and how '''side effects''' convert the logic of a Prolog program into the desired '''results'''.

As in the [[Fundamental Prolog Part 1|Part 1]] of this tutorial, we shall continue to use the '''PIE''' environment to develop and learn Prolog. We shall get into the '''Visual Prolog IDE''' only in the latter parts of this series.

==Functors==

In Part 1 of the tutorial, all the people were represented as "Bill", "John" and "Pam" etc. Now "Bill", "John" and "Pam" are just the names of the individuals. The values of the names are simple data types or '''simple domains'''. In the case of the names of the people, the '''simple domain''' was a '''string'''. Other '''simple domains''' would be '''numbers''' (e.g.: '''123''' or '''3.14'''), '''symbols''' (e.g.: '''xyz''' or '''chil_10'''), and '''characters''' (e.g.: ''''5'''' or ''''c'''').

However, individuals are represented by more characteristics than just their names. What if we need to represent all those characteristics together, instead of representing just their names? That means, we need some mechanism to represent '''compound domains'''; a collection of simpler '''domains''' held together.

In the first part of this tutorial, we had tried putting together several characteristics of individuals together, (like the '''name''' and the '''gender'''), by inserting facts into the PIE system that concentrated on '''entities''' instead of relationships. Thus we had given the following facts to the system:

<vip>person("Bill", "male").
person("John", "male").
person("Pam", "female").</vip>

However, there is another elegant method to sharpen our focus on the '''entities''' being represented.

We can package both the Name and the Gender into a package using a formalization known as a '''compound domain'''. The entire package can then be represented using a logical variable inside any Prolog clause, just like any other variables. For example, the above facts can be generically represented in a '''compound domain''' thus:

<vip>person(Name, Gender)</vip>

Note that the above statement is neither a fact nor a predicate. Logically, it states that there is some '''compound domain''' called '''person''' in the system, each of which has two characteristics, represented by the logical variables Name and Gender. The word ''person'' is known as a '''functor''', and the variables are its '''arguments'''. We shall now package our facts using these '''functors'''.

As a '''compound domain''' always has a '''functor''', we shall henceforth use the term '''functor''' in this tutorial, to represent the respective '''compound domain.'''

For now, let us modify the first example of the previous tutorial, so that we use our newly defined '''functor''' ''person'''''.'''

Please note that in the '''PIE''' (Prolog Inference Engine) that we are using, we can directly use a '''compound domain''' without any prior intimation to the Prolog engine (for example. we need NOT define a predicate or a fact called ''person'' for our code to work).

[[Image:Fundamental_Prolog_2_fig1.png]]

If you study the two facts for the father relationship, you would notice that the persons described are richer than what was done before (The earlier code is commented out in-between the tokens '''/*''' and '''*/''' .). This time, each person is described with both the person's name '''and''' his/her gender, using the person '''functor''', whereas in the earlier tutorial (Fundamental Prolog (Part1)) we were only using the person's name.

After you have written the new code, ensure that the PIE engine is reset. Use '''Engine -> Reset.''' Then, you re-consult the code using '''Engine -> Reconsult.'''

As before, on a blank line in the '''Dialog''' window type a goal (without the "?" sign- in front).

For example:

[[Image:Fundamental_Prolog_2_fig2.png]]

When the caret is placed at the end of the line, press the '''Enter''' key on your keyboard. '''PIE''' will now consider the text from the beginning of the line to the caret as a goal to execute. You should see the following result:

[[Image:Fundamental_Prolog_2_fig3.png]]

Now, you will notice that the results that are yielded are richer than what you got previously (See Tutorial 04: Fundamental Prolog (Part 1)).

==Refining Further==

If you take a look at the grandfather predicate, you would notice that it has a subtle bug: A person would have two grandfathers: one from the mother's side and one from the father's side, but the grandfather predicate as defined earlier would only yield the grandfather on the father's side.

Hence the grandfather predicate should be re-written as follows:

<vip>grandFather(Person, TheGrandFather):-
parent(Person, ParentOfPerson),
father(ParentOfPerson, TheGrandFather).</vip>

In this predicate the logic states that a father of ''any'' parent could be the grandfather of the person in consideration.

For that predicate to work, we need to define a predicate called father using the person '''functor.''' This predicate would troll through a database of facts explaining the "''parents''" defined in the system. This is a more elegant method for finding out the fathers, instead of presenting them as facts (as shown previously) because later on we can extend this concept to find out "''mothers''" in a similar fashion.

This can be done in either of the following ways:

<vip>/*1st version */
father(P, F) :-
parent(P, F),
F = person(_, "male"). %Line 2</vip>

or

<vip>/* 2nd version */
father(P, person(Name, "male")) :-
parent(P, person(Name, "male")).</vip>

The logic behind both the versions is the same, but the manner in which the logic is indicated to the Prolog engine is different. In the first version, the code in Prolog systematically examines each parent fact asserted into the code, and sees if the first logical variable (P) matches that passed down from the predicate head. If the variable does match, it checks if the second argument consists of a person '''functor''', whose second argument is the string literal "male".

This example shows one important feature of '''functors''': The arguments of a '''functor''' can be taken apart and examined using regular Prolog variables and bound values (like the string literal in this example) If you see Line 2 (Look at the side of the comment ''%Line 2'' in the code for the first version), you would notice that we have used an anonymous variable (the underscore) for the first argument of the person '''functor''' as we are (in that predicate) not interested in the name of the father.

The second version also does the same thing as the first one. But this time, as the set of parent facts is examined; on arriving at the correct value for P, the code halts and returns the correct '''functor''' data back to the predicate head, ''provided the second argument of that '''functor''' is the string literal "male"''. If you note, the functor was NOT bound to any intermediate Prolog variable, as it was done in the first version.

The second version is much terser than the first one, and sometimes this method of writing the code can be less legible to beginners.

Let us now use this code in a complete example, where we will give a suitable set of person'''' facts:

[[Image:Fundamental_Prolog_2_fig3b.png]]

Now, after you re-consult the above code into '''PIE''', and give the following goal:

<vip>grandFather(person("Pam", "female"), W)</vip>

the results would be as follows:

[[Image:Fundamental_Prolog_2_fig3c.png]]

==Functors and Predicates==

Technically, a '''functor''' represents a logical function that binds several domains together. In simpler words, a '''functor''' is a mechanism that teaches the Prolog Engine how to put together data from its component parts. It effectively puts parts of the data into a common box. You can also retrieve the parts subsequently, whenever required (like seen the previous examples). It may look like a Prolog fact or a predicate call, but it is not. It's just a piece of data, which you can handle in much the same way as a string or a number.

Please note that a '''functor''' has nothing to do with a function in other programming languages. It does not stand for some computation to be performed. It simply identifies the '''compound domain''' and holds its arguments together.

When you study the above example, you would notice that nothing special need to be done when logical variables are used to stand in for data represented by '''functors'''. The logical variable that is used to stand in for such data, is written just like any other logical variable: A word starting with a capital letter. Thus, if we take a look at the ''grandFather'' predicate in the example in this tutorial; you would notice that nothing has changed when you compare it with the same predicate that was defined in the earlier tutorial (Fundamental Prolog (part 1)). After all, the logic of that predicate has not changed. So, you would not find any changes to the variables used inside that predicate.

The biggest advantage of using '''a functor''' is that you are free to change the internal arguments of the '''functor''' without changing much of the predicates that uses such a '''functor''' as you keep revising the code.

That means, if you decide (in a later version of the code you are writing) to have one more argument for the ''person'', you still need not change anything in the ''grandfather'' predicate.

==Functors as Arguments==

In the previous section, the person '''functor''' was having two arguments: the Name and the Gender. Both happened to be simple domains i.e. '''constants''' such as "Bill" and, "male". However, there is nothing that prevents us from putting a '''functor''' itself as an '''argument''' of another '''functor'''.

Suppose, you wanted to define a '''functor''' for a ''couple'' (i.e. a husband and a wife). This is an example of how you would use such a '''functor''':

<vip>myPredicate(ACouple):-
ACouple = couple(person(Husband, "male"), person(Wife, "female")),
...</vip>

In this example, you would notice that the '''functor''' is defined by two '''functors''', each of which is a mixture of '''variables''' and '''constants'''. This can be done to reflect the logic of the data being represented. The logic used here is that a husband is always a "male" and wife is always a "female"; and a couple consists of a husband and a wife. All of which is consistent with the most common interpretation of what one means by a ''couple''.

Though in '''PIE''' you cannot predefine the kind of grammar '''functors''' can actually have; in '''Visual Prolog''' you can make such definitions. The advantage of defining a '''functor''' in such a manner is that later, when you create actual data using this '''functor''', the Prolog engine will always check if the data being created was consistent with the grammar that data was supposed to adhere to.

This comes to another characteristic of '''functors''': the ''couple'' '''functor''' has been defined with two arguments and the '''position''' of these arguments reflects their logical association. It was explained in the first part of this tutorial, that the positions of the arguments of predicates have to be formalized by the programmer, who designs the code. Once formalized; the same positional formalization should be consistently used.

The same strategy applies to the creation of '''functors''' too: In the case of the ''couple'' '''functor''', it so happened that we decided to represent the husband as the first argument, and the wife as the second one. Once this is done, then whenever data is created using such a '''functor''', then we need to ensure that the husband is always at the first position, and the wife in the second (in spite of what the women's lib people may say!)

Now, when we look back on the ''couple '' '''functor''', someone can correctly argue that if were so sure that the first argument is always a husband (who is always a male), and the second one is always a wife (who is always a female) then what is the need for making the arguments of the ''couple '' '''functor''' also as '''functors'''? Hence, an example with a more simplified ''couple '' '''functor''' would be as follows:

<vip>myPredicate(ACouple):-
ACouple=couple(Husband, Wife),
...</vip>

Hence; let us revert back to using '''functors''' for the husband and wife... but this time we will use them, because we are not sure which position is for the husband and which is for the wife.

<vip>myPredicate(Couple):-
Couple = couple(person(PersonsName, PersonsGender), person(SpouseName, SpouseGender)),
...</vip>

In the above '''functor''', both the following examples make logical sense:

<vip>myPredicate(C1):-
C1=couple(person("Bill", "male"), person("Pam", "female")),
...

/* or */
myPredicate(C2):-
C2=couple(person("Pam", "female"), person("Bill", "male")),
...</vip>

It should be pointed out that in the PIE (and many other Prolog Engines), there is no way to indicate whether a functor will receive simple domain or compound domain arguments, by looking at the variables that define the functor. This stems from the fact that in '''PIE''', '''compound domains''' are directly used, without being declared anywhere, other than in the mind of the programmer.

For example, if you wanted to use a '''compound domain''' as:

<vip>person(Name, Gender)</vip>

then '''PIE''' would as easily accept a logical variable such as:

<vip>regardingAPerson(Somebody):-
Somebody =
person("Pam",
person("Pam",
person("Pam",
person("Pam", "female")
)
)
),
...</vip>

which actually does not make any logical sense, in the current context. Luckily, '''Visual Prolog''', does a much better job of differentiating between '''simple domains''' and '''compound domains''', so, when you get to the latter tutorials, you would not have any such problems.

==Recursion Using Functors==

When data is described using '''functors''', it can be treated like any other piece of data. For example, you can write a predicate that can be made to recursively search through data which used '''compound domains''' using '''functors'''.

Let us get back briefly to the ancestor predicate, which we had used in the first part of the tutorial.

In order to determine if somebody is an ancestor of someone else, we used a recursive definition for the predicate, i.e. a definition that is defined in terms of itself. like this:

<vip>ancestor(Person, Ancestor) :- parent(Person, Ancestor).
ancestor(Person, Ancestor) :- parent(Person, P1), ancestor(P1, Ancestor).</vip>

This declaration states that a parent is an ancestor, and that an ancestor to a parent is also an ancestor. If you examine the variables in the above definition, it can very well stand for either '''simple domains''' or '''compound domains.'''

Let us define the data thus:

<vip>parent(person("Bill", "male"), person("John", "male")).
parent(person("pam", "female"), person("Bill", "male")).</vip>

If we now ask '''PIE''' to solve the following goal,

<vip>P=person("pam", "female"), ancestor(P, Who)</vip>

...this is what we will get:

[[Image:Fundamental_Prolog_2_fig4.png]]

The '''PIE''' engine has recursively examined the parent facts to reveal the two possible solutions to the answer. By the way, in the above query, you would also notice that we have bound a variable P to the person '''compound domain''' when specifying the goal to '''PIE'''. This was done to make the code more readable but it also demonstrates the fact that we can bind a piece of data specified as a '''compound domain''' into any Prolog variable.

==Strategies for Using Functors==

Software will be only as good as allowed by the modeled data. By the term ''modeling'', we mean the establishment of a relationship between the subset of the outside real-world that is being tackled with the internal data structures of the software. If the modeling of data is poor, then it is likely that the software will also be poor; or at best, inefficient. This is true of any software written in any programming language. That was the reason in the latter part of the earlier tutorial (Fundamental Prolog (part 1)), we had tried to focus on the '''entities''' and tried to correct the situation by inserting richer facts. Similarly, we introduced the concept of '''functors''' in this tutorial to get even more clarity on the data regarding '''entities''' that are being modeled.

The advantage of Prolog is that it allows easy '''description''' of the real-world data in a form that can be internally utilized by the code in an efficient manner. Simultaneously, it also makes the code very readable by fellow programmers who are working together on a project.

'''Functors''' can be used to create any type of '''compound domain''' to help in this modeling process. You would have to carefully examine the various parts of real-world data that you plan to process and convert them using '''functors''' (and other data types that you would encounter in future tutorials) keeping in mind their usage in all critical parts of the software. Some data structures that were useful in one area of the software may prove to be a hindrance in other areas.

You should take a holistic approach while zeroing in on the '''functors''' (and other data structures) you plan to use in your software. Pause and look around at all the corners of your software. Only then should you code the necessary '''functors'''.

Just thinking carefully about the data structures is not the only thing that is required. You would also need to (often simultaneously) write/modify the various goals and sub-goals (i.e. predicates) and then use the data developed thus far in those predicates. The '''side effects''' of attaining those goals and sub-goals would make your software work and you can get valuable feedback with which you can further refine your data structures.

In this tutorial, we have not fleshed out a software design holistically. We have only nibbled at bits and pieces of data which establishes the '''feel''' for some kind of real-world data concerning relationship between people (''parents'', ''grandparents'', ''families'', ''ancestors'' etc.) In forthcoming tutorials, we will use this experience to establish a '''red thread''' that connects all these tutorials together; eventually ending up with a useful software that requires such data structures.

==Conclusion==

In this lesson we learnt that data can comprise of '''simple domains''', or they can be '''compound domains''' represented using '''functors'''. We found that the arguments of '''functors''' must be positionally consistent with the logic they were meant to represent. We understood that a '''functor''' need not have just simple domains as arguments, but it can also have other '''functors''' as arguments. We then learnt that data represented as '''functors''' can be used like any regular Prolog variable, and we can even perform all operations; including recursion, on such data.

We also learnt that we must spend time modeling our subset of the real world for which we are developing the software, and get a feel for the data. We should simultaneously experiment with the predicates that you may wish to use with the data that is being modeled, so that they can be refined further.

==References==

[[Category:Fundamental Prolog Tutorial]]