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

Fundamental Prolog Part 2

2013-09-18T16:26:19Z

Gukalov: /* Recursion Using Functors */

{{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]]

Fundamental Prolog Part 2

2013-09-18T16:25:50Z

Gukalov: /* Refining Further */

{{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.jpg]]

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]]

File:Fundamental Prolog 2 fig4.png

2013-09-18T16:25:09Z

Gukalov:

File:Fundamental Prolog 2 fig3c.png

2013-09-18T16:24:54Z

Gukalov:

File:Fundamental Prolog 2 fig3b.png

2013-09-18T16:24:38Z

Gukalov:

File:Fundamental Prolog 2 fig3.png

2013-09-18T16:23:56Z

Gukalov:

Fundamental Prolog Part 2

2013-09-18T16:22:50Z

Gukalov: /* Functors */

{{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.jpg]]

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.jpg]]

==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.jpg]]

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]]

File:Fundamental Prolog 2 fig2.png

2013-09-18T16:20:51Z

Gukalov:

File:Fundamental Prolog 2 fig1.png

2013-09-18T16:20:20Z

Gukalov:

Fundamental Prolog Part 1

2013-09-18T15:46:56Z

Gukalov: /* PIE: Prolog Inference Engine */

{{FundamentalPrologNavbar}}

In this '''Prolog tutorial''' you will learn about the very fundamental ideas of Prolog language programming.

Visual Prolog is object oriented, strictly typed and mode checked.
You will of course have to master all this to write Visual Prolog programs.
But in this tutorial we will focus on the ''core'' of the code, i.e. the Prolog code when disregarding classes, types and modes.

For this purpose we will use the PIE example that is included in the Visual Prolog distribution.

PIE is a "classical" Prolog interpreter, by using this you can learn and experiment with Prolog without at all being concerned with classes, types, etc.

== Horn Clause Logic ==

Visual Prolog and other Prolog language dialects are based on Horn Clause logic.
Horn Clause logic is a formal system for reasoning about things and the way they relate to each other.

In natural language I can express a statement like:

<pre>John is the father of Bill.</pre>

Here I have two "things": John and Bill, and a "relation" between these, namely that one is the father of the other.
In Horn Clause Logic I can formalize this statement in the following way:

<vip>father("Bill", "John").</vip>

father is a predicate/relation taking two arguments, where the second is the father of the first.

'''Notice''' that '''''I '''''have chosen that the '''second''' person should be the father of the '''first'''.
I might as well have chosen it the other way around: The order of the arguments is the choice of the "designer" of the formalization.
However, once you have chosen, you must be consistent.
So in '''my''' formalization the father must '''always''' be the second person.

I have chosen to represent the persons by their names (which are string literals).
In a more complex world this would not be sufficient because many people have same name.
But for now we will be content with this simple formalization.

With formalizations like the one above I can state any kind of family relation between any persons.
But for this to become really interesting I will also have to formalize '''''rules''''' like this:

<vip>X is the grandfather of Z, if X is the father of Y and Y is the father of Z</vip>

where <vp>X</vp>, <vp>Y</vp> and <vp>Z</vp> are persons.
In Horn Clause Logic I can formalize this rule like this:

<vip>grandFather(Person, GrandFather) :-
father(Person, Father), father(Father, GrandFather).</vip>

I have chosen to use '''''variable''''' names that help understanding better than <vp>X</vp>, <vp>Y</vp> and <vp>Z</vp>.
I have also introduced a predicate for the grandfather relation.
Again I have chosen that the grandfather should be the second argument.
It is wise to be consistent like that, i.e. that the arguments of the different predicates follow some common principle.
When reading rules you should interpret :- as '''''if''''' and the comma that separates the relations as '''''and'''''.

Statements like "John is the father of Bill" are called '''''facts''''', while statements like "<vp>X</vp> is the grandfather of <vp>Z</vp>, if <vp>X</vp> is the father of <vp>Y</vp> and <vp>Y</vp> is the father of <vp>Z</vp>" are called '''''rules'''''.

With facts and rules we are ready to formulate theories.
A '''''theory''''' is a collection of facts and rules.
Let me state a little theory:

<vip>father("Bill", "John").
father("Pam", "Bill").

grandFather(Person, GrandFather) :-
father(Person, Father),
father(Father, GrandFather).</vip>

The purpose of the theory is to answer questions like these:

<vip>Is John the father of Sue?
Who is the father of Pam?
Is John the grandfather of Pam?
...</vip>

Such questions are called goals.
And they can be formalized like this (respectively):

<vip>?- father("Sue", "John").
?- father("Pam", X).
?- grandFather("Pam", "John").</vip>

Such questions are called '''''goal clauses''''' or simply '''''goals'''''.
Together ''facts'', ''rules'' and ''goals'' are called Horn clauses, hence the name Horn Clause Logic.

Some goals like the first and last are answered with a simple ''yes'' or ''no''.
For other goals like the second we seek a '''''solution''''', like <vp>X = "Bill"</vp>.

Some goals may even have many solutions.
For example:

<vip>?- father(X, Y).</vip>

has two solutions:

<vip>X = "Bill", Y = "John".
X = "Pam", Y = "Bill".</vip>

A Prolog program is a theory and a goal.
When the program starts it tries to find a solution to the goal in the theory.

== PIE: Prolog Inference Engine ==

Now we will try the little example above in PIE, the Prolog Inference Engine that comes with Visual Prolog.

Before we start you should install and build the PIE example.

*Select "Install Examples" in the Windows start menu ('''Start -> Visual Prolog -> Install Examples''').
*Open the PIE project in the IDE and '''run''' the program, as it is described in the [[Ide/Environment Overview|Environment Overview]].

When the program starts it will look like this:

[[Image:Fundamental_Prolog_1_PIE.png|Prolog Inference Engine]]

Select '''File -> New''' and enter the father and grandFather clauses above:

[[Image:Fundamental_Prolog_1_GrandFather.png|Grand Father example]]

While the editor window is active choose '''Engine -> Reconsult'''.
This will load the file into the engine.
In the '''''Dialog''''' window you should receive a message like this:

<pre>Reconsulted from: ....\pie\Exe\FILE0.PRO</pre>

Reconsult loads whatever is in the editor, '''''without''''' saving the contents to the file, if you want to save the contents use '''File -> Save'''.

'''File -> Consult''' will load the disc contents of the file regardless of whether the file is opened for editing or not.

Once you have "consulted" the theory, you can use it to answer goals.

On a blank line in the '''''Dialog''''' window type a goal (without the '''?-''' in front).

For example:

[[Image:Fundamental_Prolog_1_goal1.png|Typing a goal]]

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 a result like this:

[[Image:Fundamental_Prolog_1_goal2.png|Goal result]]

== Extending the family theory ==

It is straight forward to extend the family theory above with predicates like mother and grandMother.
You should try that yourself.
You should also add more persons.
I suggest that you use persons from your own family, because that makes it lot easier to validate, whether some person is indeed the grandMother of some other person, etc.

Given mother and father we can also define a parent predicate.
You are a parent if you are a mother; you are also a parent if you are a father.
Therefore we can define parent using two clauses like this:

<vip>parent(Person, Parent) :- mother(Person, Parent).
parent(Person, Parent) :- father(Person, Parent).</vip>

The first rule reads (recall that the second argument corresponds to the predicate name):

Parent is the parent of Person, if Parent is the mother of Person

You can also define the parent relation using semicolon ";" which means or, like this:

<vip>parent(Person, Parent) :-
mother(Person, Parent);
father(Person, Parent).</vip>

This rule reads:

Parent is the parent of Person, if Parent is the mother of Person '''''or''''' Parent is the father of Person

I will however advise you to use semicolon as little as possible (or actually not at all).
There are several reasons for this:

*The typographical difference "," and ";" is very small, but the semantic difference is rather big. ";" is often a source of confusion, since it is easily misinterpreted as ",", especially when it is on the end of a long line.
*Visual Prolog only allows to use semicolon on the outermost level (PIE will allow arbitrarily deep nesting).

Try creating a sibling predicate! Did that give problems?

You might find that siblings are found '''twice'''.
At least if you say: Two persons are siblings if they have same mother, two persons are also siblings if they have same father.
I.e. if you have rules like this:

<vip>sibling(Person, Sibling) :- mother(Person, Mother), mother(Sibling, Mother).
sibling(Person, Sibling) :- father(Person, Father), father(Sibling, Father).</vip>

The first rule reads:

Sibling is the sibling of Person, if Mother is the mother of Person '''''and''''' Mother is the mother of Sibling

The reason that you receive siblings twice is that most siblings both have same father and mother, and therefore they fulfill both requirements above.
And therefore they are found twice.

We shall not deal with this problem now; currently we will just accept that some rules give too many results.

A fullBlodedSibling predicate does not have the same problem, because it will require that both the father and the mother are the same:

<vip>fullBlodedSibling(Person, Sibling) :-
mother(Person, Mother),
mother(Sibling, Mother),
father(Person, Father),
father(Sibling, Father).</vip>

== Prolog is a Programming Language ==

From the description so far you might think that Prolog is an expert system, rather than a programming language.
And indeed Prolog can be used as an expert system, but it is designed to be a programming language.

We miss two important ingredients to turn Horn Clause logic into a programming language:

*Rigid search order/program control
*Side effects

== Program Control ==

When you try to find a solution to a goal like:

<vip>?- father(X, Y).</vip>

You can do it in many ways.
For example, you might just consider at the second fact in the theory and then you have a solution.

But Prolog does not use a "random" search strategy, instead it always use the same strategy.
The system maintains a '''''current goal''''', which is always solved from '''left to right'''.

I.e. if the current goal is:

<vip>?- grandFather(X, Y), mother(Y, Z).</vip>

Then the system will always try to solve the sub-goal grandFather(X, Y) before it solves mother(Y, Z), if the first (i.e. left-most) sub-goal cannot be solved then there is no solution to the overall problem and then the second sub-goal is not tried at all.

When solving a particular sub-goal, the facts and rules are always tried from '''top to bottom'''.

When a sub-goal is solved by using a rule, the right hand side replaces the sub-goal in the current goal.

I.e. if the current goal is:

<vip>?- grandFather(X, Y), mother(Y, Z).</vip>

And we are using the rule

<vip>grandFather(Person, GrandFather) :- father(Person, Father), father(Father, GrandFather).</vip>

to solve the first sub-goal, then the resulting current goal will be:

<vip>?- father(X, Father), father(Father, Y), mother(Y, Z).</vip>

Notice that some variables in the rule have been replaced by variables from the sub-goal.
I will explain this in details later.

Given this evaluation strategy you can interpret clauses much more '''''procedural'''''. Consider this rule:

<vip>grandFather(Person, GrandFather) :- father(Person, Father), father(Father, GrandFather).</vip>

Given the strict evaluation we can read this rule like this:

To solve grandFather(Person, GrandFather) '''first''' solve father(Person, Father) '''and then '''solve father(Father, GrandFather).

Or even like this:

When grandFather(Person, GrandFather) is '''''called''''', first '''''call''''' father(Person, Father) and then '''''call''''' father(Father, GrandFather).

With this '''''procedural '''''reading you can see that predicates correspond to procedures/subroutines in other languages.
The main difference is that a Prolog predicate can return several solutions to a single invocation or even '''''fail'''''.
This will be discussed in details in the next sections.

== Failing ==

A predicate invocation might not have any solution in the theory.
For example calling parent("Hans", X) has no solution as there are no parent facts or rules that applies to "Hans".
We say that the predicate call '''''fails'''''.
If the goal fails then there is simply no solution to the goal in the theory.
The next section will explain how failing is treated in the general case, i.e. when it is not the goal that fails.

== Backtracking ==

In the procedural interpretation of a Prolog program "or" is treated in a rather special way.
Consider the clause

<vip>parent(Person, Parent) :-
mother(Person, Parent);
father(Person, Parent).</vip>

In the logical reading we interpreted this clause as:

Parent
is the parent of Person '''if'''
Parent is the mother of
Person '''or'''
Parent is the father of Person.

The "or" introduces two possible solutions to an invocation of the parent predicate.
Prolog handles such multiple choices by first trying one choice and later (if necessary) '''''backtracking''''' to the next alternative choice, etc.

During the execution of a program a lot of alternative choices (known as '''''backtrack points''''') might exist from earlier predicate calls.
If some predicate call fails, then we will backtrack to the last backtrack point we met and try the alternative solution instead.
If no further backtrack points exists then the overall goal has failed, meaning that there was no solution to it.

With this in mind we can interpret the clause above like this:

When parent(Person, Parent) is called first record a backtrack point to the second alternative solution (i.e. to the call to father(Person, Parent)) and then call mother(Person, Parent)

A predicate that has several classes behave in a similar fashion.
Consider the clauses:

<vip>father("Bill", "John").
father("Pam", "Bill").</vip>

When father is invoked we first record a backtrack point to the second clause, and then try the first clause.

If there are three or more choices we still only create one backtrack point, but that backtrack point will start by creating another backtrack point.
Consider the clauses:

<vip>father("Bill", "John").
father("Pam", "Bill").
father("Jack", "Bill").</vip>

When father is invoked, we first record a backtrack point.
And then we try the first clause.
The backtrack point we create points to some code, which will itself create a backtrack point (namely to the third clause) and then try the second clause.
Thus all choice points have only two choices, but one choice might itself involve a choice.

'''Example''' To illustrate how programs are executed I will go through an example in details.
Consider these clauses:

<vip>mother("Bill", "Lisa").

father("Bill", "John").
father("Pam", "Bill").
father("Jack", "Bill").

parent(Person, Parent) :-
mother(Person, Parent);
father(Person, Parent).</vip>

And then consider this goal:

<vip>?- father(AA, BB), parent(BB, CC).</vip>

This goal states that we want to find three persons AA, BB and CC, such that BB is the father of AA and CC is a parent of BB.

As mentioned we always solve the goals from left to right, so first we call the father predicate.
When executing the father predicate we first create a backtrack point to the second clause, and then use the first clause.

Using the first clause we find that AA is "Bill" and BB is "John".
So we now effectively have the goal:

<vip>?- parent("John", CC).</vip>

So we call parent, which gives the following goal:

<vip>?- mother("John", CC); father("John", CC).</vip>

You will notice that the variables in the clause have been replaced with the actual parameters of the call (exactly like when you call subroutines in other languages).

The current goal is an "or" goal, so we create a backtrack point to the second alternative and pursuit the first.
We now have two active backtrack points, one to the second alternative in the parent clause, and one to the second clause in the father predicate.

After the creation of this backtrack point we are left with the following goal:

<vip>?- mother("John", CC).</vip>

So we call the mother predicate.
The mother predicate fails when the first argument is "John" (because it has no clauses that match this value in the first argument).

In case of failure we backtrack to the last backtrack point we created.
So we will now pursuit the goal:

<vip>?- father("John", CC).</vip>

When calling father this time, we will again first create a backtrack point to the second father clause.

Recall that we also still have a backtrack point to the second clause of the father predicate, which corresponds to the first call in the original goal.

We now try to use the first father clause on the goal, but that fails, because the first arguments do not match (i.e. "John" does not match "Bill").

Therefore we backtrack to the second clause, but before we use this clause we create a backtrack point to the third clause.

The second clause also fails, since "John" does not match "Pam", so we backtrack to the third clause.
This also fails, since "John" does not match "Jack".

Now we must backtrack all the way back to the first father call in the original goal; here we created a backtrack point to the second father clause.

Using the second clause we find that AA is "Pam" and BB is "Bill".
So we now effectively have the goal:

<vip>?- parent("Bill", CC).</vip>

When calling parent we now get:

<vip>?- mother("Bill", CC); father("Bill", CC).</vip>

Again we create a backtrack point to the second alternative and pursuit the first:

<vip>?- mother("Bill", CC).</vip>

This goal succeeds with CC being "Lisa".
So now we have found a solution to the goal:

<vip>AA = "Pam", BB = "Bill", CC = "Lisa".</vip>

When trying to find additional solutions we backtrack to the last backtrack point, which was the second alternative in the parent predicate:

<vip>?- father("Bill", CC).</vip>

This goal will also succeed with CC being "John".
So now we have found one more solution to the goal:

<vip>AA = "Pam", BB = "Bill", CC = "John".</vip>

If we try to find more solutions we will find:

<vip>AA = "Jack", BB = "Bill", CC = "John".
AA = "Jack", BB = "Bill", CC = "Lisa".</vip>

After that we will experience that everything will eventually fail leaving no more backtrack points.
So all in all there are four solutions to the goal.

== Improving the Family Theory ==

If you continue to work with the family relation above, you will probably find out that you have problems with relations like ''brother'' and ''sister'', because it is rather difficult to determine the sex of a person (unless the person is a father or mother).

The problem is that we have chosen a bad way to formalize our theory.

The reason that we arrived at this theory is because we started by considering the '''''relations''''' between the entities.
If we instead first focus on the '''''entities''''', then the result will naturally become different.

Our main entities are persons.
Persons have a name (in this simple context will still assume that the name identifies the person, in a real scale program this would not be true).
Persons also have a sex.
Persons have many other properties, but none of them have any interest in our context.

Therefore we define a person predicate, like this:

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

The first argument of the person predicate is the name and the second is the sex.

Instead of using mother and father as facts, I will choose to have parent as facts and mother and father as rules:

<vip>parent("Bill", "John").
parent("Pam", "Bill").

father(Person, Father) :- parent(Person, Father), person(Father, "male").</vip>

Notice that when father is a "derived" relation like this, it is impossible to state ''female'' fathers.
So this theory also has a built-in consistency on this point, which did not exist in the other formulation.

== Recursion ==

Most family relations are easy to construct given the principles above.
But when it comes to "infinite" relations like ''ancestor'' we need something more.
If we follow the principle above, we should define ancestor like this:

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

The main problem is that this line of clauses never ends.
The way to overcome this problem is to use a recursive definition, 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 are not already familiar with recursion you might find it tricky (in several senses).
Recursion is however fundamental to Prolog programming.
You will use it again and again, so eventually you will find it completely natural.

Let us try to execute an ancestor goal:

<vip>?- ancestor("Pam", AA).</vip>

We create a backtrack point to the second ancestor clause, and then we use the first, finding the new goal:

<vip>?- parent("Pam", AA).</vip>

This succeeds with the solution:

<vip>AA = "Bill".</vip>

Then we try to find another solution by using our backtrack point to the second ancestor clause.
This gives the new
goal:

<vip>?- parent("Pam", P1), ancestor(P1, AA).</vip>

Again "Bill" is the
parent of "Pam",
so we find P1=
"Bill", and then we have the goal:

<vip>?- ancestor("Bill", AA).</vip>

To solve this goal we first create a backtrack point to the second ancestor clause and then we use the first one.
This gives the following goal:

<vip>?- parent("Bill", AA).</vip>

This goal has the gives the solution:

<vip>AA = "John".</vip>

So now we have found two ancestors of "Pam":
* "Bill" and
* "John".

If we use the backtrack point to the second ancestor clause we get the following goal:

<vip>?- parent("Bill", P1), ancestor(P1, AA).</vip>

Here we will again find that
"John" is the parent of
"Bill", and thus that
P1 is
"John".
This gives the goal:

<vip>?- ancestor("John", AA).</vip>

If you pursuit this goal you will find that it will not have any solution.
So all in all we can only find two ancestors of
"Pam".

Recursion is very powerful but it can also be a bit hard to control.
Two things are important to remember:

*the recursion must make progress
*the recursion must terminate

In the code above the first clause ensures that the recursion can terminate, because this clause is not recursive (i.e. it makes no calls to the predicate itself).

In the second clause (which is recursive) we have made sure, that we go one ancestor-step further back, before making the recursive call.
I.e. we have ensured that we make some progress in the problem.

== Side Effects ==

Besides a strict evaluation order Prolog also has side effects.
For example Prolog has a number of predefined predicates for reading and writing.

The following goal will write the found ancestors of "Pam":

<vip>?- ancestor("Pam", AA), write("Ancestor of Pam : ", AA), nl().</vip>

The ancestor call will find an ancestor of "Pam" in AA.

The write call will write the string literal "Ancestor of Pam : ", and then it will write the value of AA.

The nl call will shift to a new line in the output.

When running programs in PIE, PIE itself writes solutions, so the overall effect is that your output and PIE's own output will be mixed.
This might of course not be desirable.

A very simple way to avoid PIE's own output is to make sure that the goal has no solutions.
Consider the following goal:

<vip>?- ancestor("Pam", AA), write("Ancestor of Pam : ", AA), nl(), fail.</vip>

fail is a predefined call that always fails (i.e. it has no solutions).

The first three predicate calls have exactly the same effect as above: an ancestor is found (if such one exists, of course) and then it is written.
But then we call fail this will of course '' fail''. Therefore we must pursuit a backtrack point if we have any.

When pursuing this backtrack point, we will find another ancestor (if such one exists) and write that, and then we will fail again.
And so forth.

So, we will find and write all ancestors. and eventually there will be no more backtrack points, and then the complete goal will fail.

There are a few important points to notice here:

*The goal itself did not have a single solution, but nevertheless all the solutions we wanted was given as side effects.
*Side effects in failing computations are not undone.

These points are two sides of the same thing.
But they represent different level of optimism.
The first optimistically states some possibilities that you can use, while the second is more pessimistic and states that you should be aware about using side effects, because they are not undone even if the current goal does not lead to any solution.

Anybody, who learns Prolog, will sooner or later experience unexpected output coming from failing parts of the program.
Perhaps, this little advice can help you: Separate the "calculating" code from the code that performs input/output.

In our examples above all the stated predicate are "calculating" predicates.
They all calculate some family relation.
If you need to write out, for example, "parents", create a separate predicate for writing parents and let that predicate call the "calculating" parent predicate.

== Conclusion ==

In this tutorial we have looked at some of the basic features of Prolog.
You have seen '''''facts''''', '''''rules''''' and '''''goals'''''.
You learned about the '''''execution strategy '''''for Prolog including the notion of '''''failing''''' and '''''backtracking'''''.
You have also seen that backtracking can give '''''many results '''''to a single question.
And finally you have been introduced to '''''side effects'''''.

== See also ==

* [[Fundamental Prolog Part 2]]

==References==

[[Category:Fundamental Prolog Tutorial]]

File:Fundamental Prolog 1 PIE.png

2013-09-18T15:45:54Z

Gukalov: uploaded a new version of "Image:Fundamental Prolog 1 PIE.png"

Prolog Inference Engine (PIE)

{{Tutorial Image}}

File:Fundamental Prolog 1 GrandFather.png

2013-09-18T15:45:41Z

Gukalov: uploaded a new version of "Image:Fundamental Prolog 1 GrandFather.png"

Fundaamental Prolog 1: Grandfather

{{Tutorial Image}}

File:Fundamental Prolog 1 goal2.png

2013-09-18T15:45:27Z

Gukalov: uploaded a new version of "Image:Fundamental Prolog 1 goal2.png"

Fundamental Prolog 1: goal2

{{Tutorial Image}}

File:Fundamental Prolog 1 goal1.png

2013-09-18T15:45:13Z

Gukalov: uploaded a new version of "Image:Fundamental Prolog 1 goal1.png"

Fundamental Prolog 1: goal1

{{Tutorial Image}}

Ide/Environment Overview

2013-09-18T15:26:06Z

Gukalov: /* Debugging */

{{ideNavbar|Environment Overview}}

In this tutorial I will give an overview of the Integrated Development Environment (IDE).The IDE is used to create, develop and maintain your Visual Prolog projects.

Briefly speaking you will use the IDE for the following tasks in a project life cycle:

*'''Creation''': The project is created in the IDE, at creation time you choose important properties of your project, such as whether the project is an executable or a DLL, whether it uses GUI or is text based, etc.

*'''Building''': The project is built, i.e. compiled and linked, from the IDE.

*'''Browsing''': The IDE and the compiler collect information about the project, which is utilized in various ways for quick localization of entities, etc.

*'''Development''': During the development and maintenance of the project, the IDE is used to add and remove source files and GUI entities to the project and to edit these.

*'''Debugging''': The IDE is also used for debugging the project. The debugger is used to follow program execution and exploit the program state when the program runs.In the sequel we will look more detailed at each of these things.

'''Notice''' that the tutorial will start from scratch and create a project that is used for the whole tutorial. The reader is encouraged to do the same. Also notice that clicking on reduced pictures will show them in full scale in a separate window.

==Creation==

First we will create a project by selecting '''Project -> New...''' in the menu. In response to this you are presented to a dialog containing various properties of the project.

[[Image:tut01_projectSettingsS.png]]

I have chosen that my project should have the name ''tut01''.

The project name is also used as the name of the target that is produced. In this case the target is an ''exe'' file so the target name will be ''tut01.exe''.

I have also chosen that the target should be a GUI program, i.e. a program with a graphical user interface.

The '''Base Directory''' is the "base" of all your projects; you should choose a place that is convenient for you.

The new project will be created in a '''Sub-Directory''' of the base directory. By default this directory have the same name as the project itself.

The '''Package Prefix''' is used when creating new "packages" in the system (a later tutorial will explain about the package notion). In case your source files will ever be shared with somebody else it is a good idea if the prefix does not conflict with other prefixes. Therefore it is a good idea to use a prefix that start with a reverse Internet domain name, like ''com/visual-prolog ''(which is the reverse of ''visual-prolog.com'').

For the moment you do not need to consider the remaining tabs and options.

Now create the project by pressing '''OK'''.

The IDE will now look something like this:

[[Image:tut01_totalS.png]]

You have the '''Project Window''', which contains information about the entities in your project.
You have the '''Messages Window''', which will contain various status and progress messages.

==Building==

Before we make any modifications, we will build (i.e. compile and link) the project. In the '''Build''' menu you find commands for building, compiling and executing the project.

If you choose '''Execute''' the project is first build, so that it is an up to date version you execute. Therefore I will choose '''Execute'''.

If you have not registered Visual Prolog you will be presented to a special screen telling you so. I will suggest that you register, but you can also choose "Continue Evaluation".

In the '''Messages Window''' the IDE writes which files are compiled, etc.

If the build process succeeds, which it does in this case, the created program is executed. As a result you will see a little ''doing-nothing ''GUI program. You might notice that the program looks a bit like the IDE itself. This is no coincidence since the IDE is actually a Visual Prolog program.

Later in this tutorial we will also see what happens, if the compiler or the linker detects errors in the build process.

==Browsing==

Right now we will turn our eyes to the '''Project Tree''' in the '''Project Window''', and explore that a bit. The tree itself is presented in a standard Windows tree control so you should already be familiar with its usage. Here we shall concentrate on the contents of the tree.

Right now the project tree will look like this:

[[Image:tut01_projectWindow1.png|Project Tree]]

The top node represents the project, and the project directory.

Right below that is the logical node '''$(ProDir)''' which represents the directory in which Visual Prolog is installed. This directory contains (as we shall shortly see) libraries and library code from the Visual Prolog system.

Then comes another directory '''TaskWindow,''' which is a subdirectory of the project directory. This directory contains all the code needed to produce the Task Window, its menu and toolbar and the about dialog.

Finally, you see a number of files. Visual Prolog uses the following conventions:

*.'''ph''' files are '''package headers'''. A package is a collection of classes and interfaces that are intended to be used as a chunk.
*.'''pack''' files are '''packages'''. They contain the implementation/definition of the corresponding .ph files.
*.'''i''' file contains an '''interface'''.
*.'''cl''' file contains a '''class declaration'''
*.'''pro''' file contains a '''class implementation'''

If you expand the main.cl node completely you will see the following:

[[Image:tut01_projectWindow2.png|Project Tree]]

This sub-tree shows that the file '''main.cl''' contains a class called '''main''', which contains two predicates called classinfo and run respectively. Predicates are subroutines, but they will not be considered further in this tutorial.

If we collapse this node again and instead expand the '''TaskWindow''' node, you will see this tree:

You will notice several new kinds of nodes:

*.'''dlg''' file contains a '''dialog'''

*.'''frm''' file contains a '''form'''

*.'''win''' file contains a '''window''' (task window or conventional PFC GUI window)

*.'''mnu''' file contains a '''menu'''

*.'''ico''' file contains an '''icon'''

If you continue to explore you might also meet:

[[Image:tut01_projectWindow3.png|Project Tree: TaskWindow]]

*.'''ctl''' files containing '''controls'''

*.'''tb''' files containing '''toolbars'''

*.'''cur''' files containing '''cursors'''

*.'''bmp''' files containing '''bitmaps'''

*.'''lib''' that are '''libraries'''

If you right click on a node a context menu will appear, with commands that have relevance for that particular node.

If you double click on a node the corresponding entity will be brought up in a suitable editor. All code is edited in a text editor, but windows resources like dialogs and menus are edited in graphical editors. We will look closer to graphical editors below, here we shall try to bring up a text editor.

Some entities are represented twice in the tree, because they have both a declaration and a definition/implementation. For example, the predicate run in the class '''tut01''':

[[Image:tut01_projectWindow2.png|Project Tree]] [[Image:tut01_projectWindow4.png|Project Tree]]

Try double clicking on each of the run nodes, and notice that two editors open showing the declaration and the definition of the run predicate, respectively.

The IDE has other facilities for browsing to specific entities, but these will not be considered here.

==Development==

Now lets try to modify the project a bit. Since we have not yet concerned ourselves with how to program in Visual Prolog, we will keep the changes simple.

We will start by deliberately introducing an error, that way you will not be completely surprised if you make some thing wrong, at the same time you can see the error window.

First you should locate the clauses for the run predicate in the file '''main.pro'''. If you double click the last of the two run nodes in the project tree, an editor opens with the caret placed like this:

[[Image:tut01_editRun1S.png]]

Try inserting a fail like this (notice the comma after show):

<vip>clauses
run():-
TaskWindow = taskWindow::new(),
TaskWindow:show(),
fail.</vip>

After that we try to build the project again: simply press the '''Ctrl+Shift+B''' key combination. The system will now save and compile the file, but since we have made an error, the '''Error Window''' will open:

[[Image:tut01_errorS.png|Error Wondow]]

We will consider what the error message actually means. Instead you should try to double-click on the error message. You will notice that the editor gets focus again and that the caret points exactly to the fail we inserted.

Reestablish the code without the fail and build the project again.

Next we will try to make a modification in the about dialog. It is not a very sensible change, but it will illustrate a number of things.

First we will open the '''About''' dialog in the '''Dialog Editor''', to do this you double click the dialog in the project tree. The node you have to double click is shown here:

[[Image:tut01_projectWindowAbout.png|Project Window: About Dialog]]

Once you have clicked it you will see the dialog in the '''Dialog Editor''', two toolbars and properties window.

We will add a button to the dialog. You click on the "button" on the controls toolbar, and then you click in the dialog next to the project icon in the '''AboutDialog''' window. As a result you can see the properties of the new control and you can edit them. I have changed the '''Text''' to "Press Me", this is the text that will appear on the button. I can also see the '''Name''' field, the IDE will identify this particular control in various contexts by this Name.

Now it should look something like this:

[[Image:tut01_dialogEditorAbout2.png|Dialog Editor: About Dialog with new button]]

Now we want to do something whenever the button is pressed:

[[Image:Tut01_dialogEditorAboutClick.png]]

The IDE has suggested the name onPushButton for the handling predicate. If you double-click the line corresponding to the event, an editor will open positioned at the newly inserted code.

We will change the button text when the button is pressed. To do this we modify the code as follows:

<vip>predicates
onPushButtonClick : button::clickResponder.
clauses
onPushButtonClick(_Source) = button::defaultAction() :-
pushButton_ctl:setText("Pressed").</vip>

Now try to build and execute the program again (i.e. press the '''Ctrl+Shift+B''' key combination). If you have followed the steps carefully this should be a success. In the program you should of course open the '''About''' dialog, by selecting the menu entry '''Help -> About'''; and then press the new button.

This is how it looked in my application:

[[Image:tut01_AboutPressMe.png|About: Press Me]][[Image:tut01_AboutPressed.png|About Pressed]]

==Debugging==

The development environment contains a debugger. With the debugger you can trace the execution of your program and examine the program state.

It does not make much sense to go into details with debugging before you have learned the Visual Prolog language. But I will briefly explain the debugger anyway, because it can be very useful for understanding and experimenting with the language.

To start the debugger, select '''Debug -> Run''' in the menu. If the project is not up-to-date it will first be build, after that the debugging session will start.

'''Notice''' you can stop the debugging at any time by selecting '''Debug -> Stop Debugging''' in the menu.

When debugging starts the IDE will first load the debug information and then it will enter the program. The program execution is stopped just before the goal is executed. To indicate this, the goal is opened in an editor window, and the blue arrow points to the goal:

[[Image:tut01_debug1.png|Editor: Current Position]]

You can single step in the program using the '''Step Into '''and '''Step Over''' commands in the '''Debug '''menu.

Try '''Step Into''': this will open another editor with the code of mainExe::run, and the arrow will point to the entry of this code.

In the view menu you can open various debugger windows, which I will briefly explain.

The '''Run Stack''' window:

[[Image:tut01_runStack.png|Run Stack]]

contains a "picture" of the run stack. In principle, the run stack contains a number of lines corresponding to calls that has been made. However, optimization (so called last call optimization) might have removed some entries.

The run stack not only shows the calls, it also shows trap points and backtrack points, these is described in a later tutorial and there I also describe the run stack window in more details.

The '''Local Variables''' window:

[[Image:tut01_localVariables.png|Local Variables]]

contains the local variables corresponding to the selection in the run stack window. Some variables might not yet have received a value, these are show as an underscore (i.e. like originalraiser in the above picture).

The '''Facts''' window:

[[Image:tut01_factsWindow.png|Facts]]

Contains the global state of the program, this state is stored in fact databases. ''Fact databases ''are a unique Visual Prolog feature, which will be described in a later tutorial. You can also add objects from the '''Local Variables '''window to the '''Facts''' window, that way you can track the state changes in interesting objects.

The '''Breakpoints '''window:

[[Image:tut01_breakPointsWindow.png]]

shows the current breakpoints in the program (I have set open breakpoint so that the window would not be empty). You can set/remove breakpoints by selecting '''Debug -> Toggle Breakpoint'''.

The remaining debug windows are for low level debugging and will not be considered here.

==Summary==

The Integrated Development Environment (IDE) makes it possible for you to:

*create

*build

*maintain, and

*debug

your projects. It contains a number of tools, editor and wizards that will help you in your tasks.

[[ru:Среда_разработки]]
[[Category:Tutorials]]

File:Tut01 runStack.png

2013-09-18T15:24:48Z

Gukalov: uploaded a new version of "Image:Tut01 runStack.png"

Environment Overview: Debug: Run stack

{{Tutorial Image}}

File:Tut01 localVariables.png

2013-09-18T15:24:23Z

Gukalov: uploaded a new version of "Image:Tut01 localVariables.png"

Environment Overview: Debug: Variables window

{{Tutorial Image}}

File:Tut01 factsWindow.png

2013-09-18T15:24:02Z

Gukalov: uploaded a new version of "Image:Tut01 factsWindow.png"

Environment Overview: Debug: Facts window

{{Tutorial Image}}

File:Tut01 debug1.png

2013-09-18T15:23:40Z

Gukalov: uploaded a new version of "Image:Tut01 debug1.png"

Environment Overview: Debug: editor window

{{Tutorial Image}}

File:Tut01 breakPointsWindow.png

2013-09-18T15:23:21Z

Gukalov: uploaded a new version of "Image:Tut01 breakPointsWindow.png"

Environment Overview: Debug: Breakpoints window

{{Tutorial Image}}

File:Tut01 AboutPressed.png

2013-09-18T15:09:35Z

Gukalov: uploaded a new version of "Image:Tut01 AboutPressed.png"

Environment Overview: Running about dialog: Pressed

{{Tutorial Image}}

File:Tut01 AboutPressMe.png

2013-09-18T15:09:23Z

Gukalov: uploaded a new version of "Image:Tut01 AboutPressMe.png"

Environment Overview: Running about dialog: Press Me

{{Tutorial Image}}

File:Tut01 dialogEditorAboutClick.png

2013-09-18T14:59:20Z

Gukalov:

Ide/Environment Overview

2013-09-18T14:58:53Z

Gukalov: /* Development */

{{ideNavbar|Environment Overview}}

In this tutorial I will give an overview of the Integrated Development Environment (IDE).The IDE is used to create, develop and maintain your Visual Prolog projects.

Briefly speaking you will use the IDE for the following tasks in a project life cycle:

*'''Creation''': The project is created in the IDE, at creation time you choose important properties of your project, such as whether the project is an executable or a DLL, whether it uses GUI or is text based, etc.

*'''Building''': The project is built, i.e. compiled and linked, from the IDE.

*'''Browsing''': The IDE and the compiler collect information about the project, which is utilized in various ways for quick localization of entities, etc.

*'''Development''': During the development and maintenance of the project, the IDE is used to add and remove source files and GUI entities to the project and to edit these.

*'''Debugging''': The IDE is also used for debugging the project. The debugger is used to follow program execution and exploit the program state when the program runs.In the sequel we will look more detailed at each of these things.

'''Notice''' that the tutorial will start from scratch and create a project that is used for the whole tutorial. The reader is encouraged to do the same. Also notice that clicking on reduced pictures will show them in full scale in a separate window.

==Creation==

First we will create a project by selecting '''Project -> New...''' in the menu. In response to this you are presented to a dialog containing various properties of the project.

[[Image:tut01_projectSettingsS.png]]

I have chosen that my project should have the name ''tut01''.

The project name is also used as the name of the target that is produced. In this case the target is an ''exe'' file so the target name will be ''tut01.exe''.

I have also chosen that the target should be a GUI program, i.e. a program with a graphical user interface.

The '''Base Directory''' is the "base" of all your projects; you should choose a place that is convenient for you.

The new project will be created in a '''Sub-Directory''' of the base directory. By default this directory have the same name as the project itself.

The '''Package Prefix''' is used when creating new "packages" in the system (a later tutorial will explain about the package notion). In case your source files will ever be shared with somebody else it is a good idea if the prefix does not conflict with other prefixes. Therefore it is a good idea to use a prefix that start with a reverse Internet domain name, like ''com/visual-prolog ''(which is the reverse of ''visual-prolog.com'').

For the moment you do not need to consider the remaining tabs and options.

Now create the project by pressing '''OK'''.

The IDE will now look something like this:

[[Image:tut01_totalS.png]]

You have the '''Project Window''', which contains information about the entities in your project.
You have the '''Messages Window''', which will contain various status and progress messages.

==Building==

Before we make any modifications, we will build (i.e. compile and link) the project. In the '''Build''' menu you find commands for building, compiling and executing the project.

If you choose '''Execute''' the project is first build, so that it is an up to date version you execute. Therefore I will choose '''Execute'''.

If you have not registered Visual Prolog you will be presented to a special screen telling you so. I will suggest that you register, but you can also choose "Continue Evaluation".

In the '''Messages Window''' the IDE writes which files are compiled, etc.

If the build process succeeds, which it does in this case, the created program is executed. As a result you will see a little ''doing-nothing ''GUI program. You might notice that the program looks a bit like the IDE itself. This is no coincidence since the IDE is actually a Visual Prolog program.

Later in this tutorial we will also see what happens, if the compiler or the linker detects errors in the build process.

==Browsing==

Right now we will turn our eyes to the '''Project Tree''' in the '''Project Window''', and explore that a bit. The tree itself is presented in a standard Windows tree control so you should already be familiar with its usage. Here we shall concentrate on the contents of the tree.

Right now the project tree will look like this:

[[Image:tut01_projectWindow1.png|Project Tree]]

The top node represents the project, and the project directory.

Right below that is the logical node '''$(ProDir)''' which represents the directory in which Visual Prolog is installed. This directory contains (as we shall shortly see) libraries and library code from the Visual Prolog system.

Then comes another directory '''TaskWindow,''' which is a subdirectory of the project directory. This directory contains all the code needed to produce the Task Window, its menu and toolbar and the about dialog.

Finally, you see a number of files. Visual Prolog uses the following conventions:

*.'''ph''' files are '''package headers'''. A package is a collection of classes and interfaces that are intended to be used as a chunk.
*.'''pack''' files are '''packages'''. They contain the implementation/definition of the corresponding .ph files.
*.'''i''' file contains an '''interface'''.
*.'''cl''' file contains a '''class declaration'''
*.'''pro''' file contains a '''class implementation'''

If you expand the main.cl node completely you will see the following:

[[Image:tut01_projectWindow2.png|Project Tree]]

This sub-tree shows that the file '''main.cl''' contains a class called '''main''', which contains two predicates called classinfo and run respectively. Predicates are subroutines, but they will not be considered further in this tutorial.

If we collapse this node again and instead expand the '''TaskWindow''' node, you will see this tree:

You will notice several new kinds of nodes:

*.'''dlg''' file contains a '''dialog'''

*.'''frm''' file contains a '''form'''

*.'''win''' file contains a '''window''' (task window or conventional PFC GUI window)

*.'''mnu''' file contains a '''menu'''

*.'''ico''' file contains an '''icon'''

If you continue to explore you might also meet:

[[Image:tut01_projectWindow3.png|Project Tree: TaskWindow]]

*.'''ctl''' files containing '''controls'''

*.'''tb''' files containing '''toolbars'''

*.'''cur''' files containing '''cursors'''

*.'''bmp''' files containing '''bitmaps'''

*.'''lib''' that are '''libraries'''

If you right click on a node a context menu will appear, with commands that have relevance for that particular node.

If you double click on a node the corresponding entity will be brought up in a suitable editor. All code is edited in a text editor, but windows resources like dialogs and menus are edited in graphical editors. We will look closer to graphical editors below, here we shall try to bring up a text editor.

Some entities are represented twice in the tree, because they have both a declaration and a definition/implementation. For example, the predicate run in the class '''tut01''':

[[Image:tut01_projectWindow2.png|Project Tree]] [[Image:tut01_projectWindow4.png|Project Tree]]

Try double clicking on each of the run nodes, and notice that two editors open showing the declaration and the definition of the run predicate, respectively.

The IDE has other facilities for browsing to specific entities, but these will not be considered here.

==Development==

Now lets try to modify the project a bit. Since we have not yet concerned ourselves with how to program in Visual Prolog, we will keep the changes simple.

We will start by deliberately introducing an error, that way you will not be completely surprised if you make some thing wrong, at the same time you can see the error window.

First you should locate the clauses for the run predicate in the file '''main.pro'''. If you double click the last of the two run nodes in the project tree, an editor opens with the caret placed like this:

[[Image:tut01_editRun1S.png]]

Try inserting a fail like this (notice the comma after show):

<vip>clauses
run():-
TaskWindow = taskWindow::new(),
TaskWindow:show(),
fail.</vip>

After that we try to build the project again: simply press the '''Ctrl+Shift+B''' key combination. The system will now save and compile the file, but since we have made an error, the '''Error Window''' will open:

[[Image:tut01_errorS.png|Error Wondow]]

We will consider what the error message actually means. Instead you should try to double-click on the error message. You will notice that the editor gets focus again and that the caret points exactly to the fail we inserted.

Reestablish the code without the fail and build the project again.

Next we will try to make a modification in the about dialog. It is not a very sensible change, but it will illustrate a number of things.

First we will open the '''About''' dialog in the '''Dialog Editor''', to do this you double click the dialog in the project tree. The node you have to double click is shown here:

[[Image:tut01_projectWindowAbout.png|Project Window: About Dialog]]

Once you have clicked it you will see the dialog in the '''Dialog Editor''', two toolbars and properties window.

We will add a button to the dialog. You click on the "button" on the controls toolbar, and then you click in the dialog next to the project icon in the '''AboutDialog''' window. As a result you can see the properties of the new control and you can edit them. I have changed the '''Text''' to "Press Me", this is the text that will appear on the button. I can also see the '''Name''' field, the IDE will identify this particular control in various contexts by this Name.

Now it should look something like this:

[[Image:tut01_dialogEditorAbout2.png|Dialog Editor: About Dialog with new button]]

Now we want to do something whenever the button is pressed:

[[Image:Tut01_dialogEditorAboutClick.png]]

The IDE has suggested the name onPushButton for the handling predicate. If you double-click the line corresponding to the event, an editor will open positioned at the newly inserted code.

We will change the button text when the button is pressed. To do this we modify the code as follows:

<vip>predicates
onPushButtonClick : button::clickResponder.
clauses
onPushButtonClick(_Source) = button::defaultAction() :-
pushButton_ctl:setText("Pressed").</vip>

Now try to build and execute the program again (i.e. press the '''Ctrl+Shift+B''' key combination). If you have followed the steps carefully this should be a success. In the program you should of course open the '''About''' dialog, by selecting the menu entry '''Help -> About'''; and then press the new button.

This is how it looked in my application:

[[Image:tut01_AboutPressMe.png|About: Press Me]][[Image:tut01_AboutPressed.png|About Pressed]]

==Debugging==

The development environment contains a debugger. With the debugger you can trace the execution of your program and examine the program state.

It does not make much sense to go into details with debugging before you have learned the Visual Prolog language. But I will briefly explain the debugger anyway, because it can be very useful for understanding and experimenting with the language.

To start the debugger, select '''Debug -> Run''' in the menu. If the project is not up-to-date it will first be build, after that the debugging session will start.

'''Notice''' you can stop the debugging at any time by selecting '''Debug -> Stop Debugging''' in the menu.

When debugging starts the IDE will first load the debug information and then it will enter the program. The program execution is stopped just before the goal is executed. To indicate this, the goal is opened in an editor window, and the blue arrow points to the goal:

[[Image:tut01_debug1.png|Editor: Current Position]]

You can single step in the program using the '''Step Into '''and '''Step Over''' commands in the '''Debug '''menu.

Try '''Step Into''': this will open another editor with the code of mainExe::run, and the arrow will point to the entry of this code.

In the view menu you can open various debugger windows, which I will briefly explain.

The '''Run Stack''' window:

[[Image:tut01_runStack.png|Run Stack]]

contains a "picture" of the run stack. Exactly what you see depends on your settings in '''Tools -> Options... -> Debugger'''. In principle, the run stack contains a number of lines corresponding to calls that has been made. However, optimization (so called last call optimization) might have removed some entries.

The run stack not only shows the calls, it also shows trap points and backtrack points, these is described in a later tutorial and there I also describe the run stack window in more details.

The '''Local Variables''' window:

[[Image:tut01_localVariables.png|Local Variables]]

contains the local variables corresponding to the selection in the run stack window. Some variables might not yet have received a value, these are show as an underscore (i.e. like originalraiser in the above picture).

The '''Facts''' window:

[[Image:tut01_factsWindow.png|Facts]]

Contains the global state of the program, this state is stored in fact databases. ''Fact databases ''are a unique Visual Prolog feature, which will be described in a later tutorial. You can also add objects from the '''Local Variables '''window to the '''Facts''' window, that way you can track the state changes in interesting objects.

The '''Breakpoints '''window:

[[Image:tut01_breakPointsWindow.png]]

shows the current breakpoints in the program (I have set open breakpoint so that the window would not be empty). You can set/remove breakpoints by selecting '''Debug -> Toggle Breakpoint'''.

The remaining debug windows are for low level debugging and will not be considered here.

==Summary==

The Integrated Development Environment (IDE) makes it possible for you to:

*create

*build

*maintain, and

*debug

your projects. It contains a number of tools, editor and wizards that will help you in your tasks.

[[ru:Среда_разработки]]
[[Category:Tutorials]]

File:Tut01 dialogEditorAbout2.png

2013-09-18T14:50:39Z

Gukalov: uploaded a new version of "Image:Tut01 dialogEditorAbout2.png"

Environment Overview: About dialog in dialog editor

{{Tutorial Image}}

File:Tut01 projectWindowAbout.png

2013-09-18T14:49:40Z

Gukalov: uploaded a new version of "Image:Tut01 projectWindowAbout.png"

Environment Overview: About dialog in project window

{{Tutorial Image}}

File:Tut01 errorS.png

2013-09-18T14:41:58Z

Gukalov: uploaded a new version of "Image:Tut01 errorS.png"

Environment Overview: Error window

{{Tutorial Image}}

File:Tut01 editRun1S.png

2013-09-18T14:41:30Z

Gukalov: uploaded a new version of "Image:Tut01 editRun1S.png"

Environment Overview: Go to run predicate in editor

{{Tutorial Image}}

File:Tut01 projectWindow4.png

2013-09-18T14:33:21Z

Gukalov: uploaded a new version of "Image:Tut01 projectWindow4.png"

Environment Overview: Project Window 4

{{Tutorial Image}}

File:Tut01 projectWindow3.png

2013-09-18T14:32:29Z

Gukalov: uploaded a new version of "Image:Tut01 projectWindow3.png"

Environment Overview: Project Window 3

{{Tutorial Image}}

File:Tut01 projectWindow2.png

2013-09-18T14:31:00Z

Gukalov: uploaded a new version of "Image:Tut01 projectWindow2.png"

Environment Overview: Project Window 2

{{Tutorial Image}}

File:Tut01 projectWindow1.png

2013-09-18T14:30:02Z

Gukalov: uploaded a new version of "Image:Tut01 projectWindow1.png"

Environment Overview: Project Window 1

{{Tutorial Image}}

File:Tut01 projectSettingsS.png

2013-09-18T14:11:06Z

Gukalov:

File:Tut01 totalS.png

2013-09-18T14:07:30Z

Gukalov:

Ide/Environment Overview

2013-09-18T13:40:04Z

Gukalov: /* Creation */

{{ideNavbar|Environment Overview}}

In this tutorial I will give an overview of the Integrated Development Environment (IDE).The IDE is used to create, develop and maintain your Visual Prolog projects.

Briefly speaking you will use the IDE for the following tasks in a project life cycle:

*'''Creation''': The project is created in the IDE, at creation time you choose important properties of your project, such as whether the project is an executable or a DLL, whether it uses GUI or is text based, etc.

*'''Building''': The project is built, i.e. compiled and linked, from the IDE.

*'''Browsing''': The IDE and the compiler collect information about the project, which is utilized in various ways for quick localization of entities, etc.

*'''Development''': During the development and maintenance of the project, the IDE is used to add and remove source files and GUI entities to the project and to edit these.

*'''Debugging''': The IDE is also used for debugging the project. The debugger is used to follow program execution and exploit the program state when the program runs.In the sequel we will look more detailed at each of these things.

'''Notice''' that the tutorial will start from scratch and create a project that is used for the whole tutorial. The reader is encouraged to do the same. Also notice that clicking on reduced pictures will show them in full scale in a separate window.

==Creation==

First we will create a project by selecting '''Project -> New...''' in the menu. In response to this you are presented to a dialog containing various properties of the project.

[[Image:tut01_projectSettingsS.png]]

I have chosen that my project should have the name ''tut01''.

The project name is also used as the name of the target that is produced. In this case the target is an ''exe'' file so the target name will be ''tut01.exe''.

I have also chosen that the target should be a GUI program, i.e. a program with a graphical user interface.

The '''Base Directory''' is the "base" of all your projects; you should choose a place that is convenient for you.

The new project will be created in a '''Sub-Directory''' of the base directory. By default this directory have the same name as the project itself.

The '''Package Prefix''' is used when creating new "packages" in the system (a later tutorial will explain about the package notion). In case your source files will ever be shared with somebody else it is a good idea if the prefix does not conflict with other prefixes. Therefore it is a good idea to use a prefix that start with a reverse Internet domain name, like ''com/visual-prolog ''(which is the reverse of ''visual-prolog.com'').

For the moment you do not need to consider the remaining tabs and options.

Now create the project by pressing '''OK'''.

The IDE will now look something like this:

[[Image:tut01_totalS.png]]

You have the '''Project Window''', which contains information about the entities in your project.
You have the '''Messages Window''', which will contain various status and progress messages.

==Building==

Before we make any modifications, we will build (i.e. compile and link) the project. In the '''Build''' menu you find commands for building, compiling and executing the project.

If you choose '''Execute''' the project is first build, so that it is an up to date version you execute. Therefore I will choose '''Execute'''.

If you have not registered Visual Prolog you will be presented to a special screen telling you so. I will suggest that you register, but you can also choose "Continue Evaluation".

In the '''Messages Window''' the IDE writes which files are compiled, etc.

If the build process succeeds, which it does in this case, the created program is executed. As a result you will see a little ''doing-nothing ''GUI program. You might notice that the program looks a bit like the IDE itself. This is no coincidence since the IDE is actually a Visual Prolog program.

Later in this tutorial we will also see what happens, if the compiler or the linker detects errors in the build process.

==Browsing==

Right now we will turn our eyes to the '''Project Tree''' in the '''Project Window''', and explore that a bit. The tree itself is presented in a standard Windows tree control so you should already be familiar with its usage. Here we shall concentrate on the contents of the tree.

Right now the project tree will look like this:

[[Image:tut01_projectWindow1.png|Project Tree]]

The top node represents the project, and the project directory.

Right below that is the logical node '''$(ProDir)''' which represents the directory in which Visual Prolog is installed. This directory contains (as we shall shortly see) libraries and library code from the Visual Prolog system.

Then comes another directory '''TaskWindow,''' which is a subdirectory of the project directory. This directory contains all the code needed to produce the Task Window, its menu and toolbar and the about dialog.

Finally, you see a number of files. Visual Prolog uses the following conventions:

*.'''ph''' files are '''package headers'''. A package is a collection of classes and interfaces that are intended to be used as a chunk.
*.'''pack''' files are '''packages'''. They contain the implementation/definition of the corresponding .ph files.
*.'''i''' file contains an '''interface'''.
*.'''cl''' file contains a '''class declaration'''
*.'''pro''' file contains a '''class implementation'''

If you expand the main.cl node completely you will see the following:

[[Image:tut01_projectWindow2.png|Project Tree]]

This sub-tree shows that the file '''main.cl''' contains a class called '''main''', which contains two predicates called classinfo and run respectively. Predicates are subroutines, but they will not be considered further in this tutorial.

If we collapse this node again and instead expand the '''TaskWindow''' node, you will see this tree:

You will notice several new kinds of nodes:

*.'''dlg''' file contains a '''dialog'''

*.'''frm''' file contains a '''form'''

*.'''win''' file contains a '''window''' (task window or conventional PFC GUI window)

*.'''mnu''' file contains a '''menu'''

*.'''ico''' file contains an '''icon'''

If you continue to explore you might also meet:

[[Image:tut01_projectWindow3.png|Project Tree: TaskWindow]]

*.'''ctl''' files containing '''controls'''

*.'''tb''' files containing '''toolbars'''

*.'''cur''' files containing '''cursors'''

*.'''bmp''' files containing '''bitmaps'''

*.'''lib''' that are '''libraries'''

If you right click on a node a context menu will appear, with commands that have relevance for that particular node.

If you double click on a node the corresponding entity will be brought up in a suitable editor. All code is edited in a text editor, but windows resources like dialogs and menus are edited in graphical editors. We will look closer to graphical editors below, here we shall try to bring up a text editor.

Some entities are represented twice in the tree, because they have both a declaration and a definition/implementation. For example, the predicate run in the class '''tut01''':

[[Image:tut01_projectWindow2.png|Project Tree]] [[Image:tut01_projectWindow4.png|Project Tree]]

Try double clicking on each of the run nodes, and notice that two editors open showing the declaration and the definition of the run predicate, respectively.

The IDE has other facilities for browsing to specific entities, but these will not be considered here.

==Development==

Now lets try to modify the project a bit. Since we have not yet concerned ourselves with how to program in Visual Prolog, we will keep the changes simple.

We will start by deliberately introducing an error, that way you will not be completely surprised if you make some thing wrong, at the same time you can see the error window.

First you should locate the clauses for the run predicate in the file '''main.pro'''. If you double click the last of the two run nodes in the project tree, an editor opens with the caret placed like this:

[[Image:tut01_editRun1S.png]]

Try inserting a fail like this (notice the comma after show):

<vip>clauses
run():-
TaskWindow = taskWindow::new(),
TaskWindow:show(),
fail.</vip>

After that we try to build the project again: simply press the '''Ctrl+Shift+B''' key combination. The system will now save and compile the file, but since we have made an error, the '''Error Window''' will open:

[[Image:tut01_errorS.png|Error Wondow]]

We will consider what the error message actually means. Instead you should try to double-click on the error message. You will notice that the editor gets focus again and that the caret points exactly to the fail we inserted.

Reestablish the code without the fail and build the project again.

Next we will try to make a modification in the about dialog. It is not a very sensible change, but it will illustrate a number of things.

First we will open the '''About''' dialog in the '''Dialog Editor''', to do this you double click the dialog in the project tree. The node you have to double click is shown here:

[[Image:tut01_projectWindowAbout.png|Project Window: About Dialog]]

Once you have clicked it you will see the dialog in the '''Dialog Editor''', two toolbars and properties window.

We will add a button to the dialog. You click on the "button" on the controls toolbar, and then you click in the dialog next to the project icon in the '''AboutDialog''' window. As a result you can see the properties of the new control and you can edit them. I have changed the '''Text''' to "Press Me", this is the text that will appear on the button. I can also see the '''Name''' field, the IDE will identify this particular control in various contexts by this Name.

Now it should look something like this:

[[Image:tut01_dialogEditorAbout2.png|Dialog Editor: About Dialog with new button]]

Now we want to do something whenever the button is pressed. To do this we will open the '''Code Expert''': Right click the dialog and select '''Code Expert'''. The code expert will open and I have located my button.

The blue dot indicates that the control is not handled. The IDE has suggested the name onPushButton for the handling predicate. We will choose '''Add''' to add this predicate to our code and to bind it to this control.

If you double-click the line corresponding to the control in the code expert, an editor will open positioned at the newly inserted code.

We will change the button text when the button is pressed. To do this we modify the code as follows:

<vip>predicates
onPushButtonClick : button::clickResponder.
clauses
onPushButtonClick(_Source) = button::defaultAction() :-
pushButton_ctl:setText("Pressed").</vip>

Now try to build and execute the program again (i.e. press the '''Ctrl+Shift+B''' key combination). If you have followed the steps carefully this should be a success. In the program you should of course open the '''About''' dialog, by selecting the menu entry '''Help -> About'''; and then press the new button.

This is how it looked in my application:

[[Image:tut01_AboutPressMe.png|About: Press Me]][[Image:tut01_AboutPressed.png|About Pressed]]

==Debugging==

The development environment contains a debugger. With the debugger you can trace the execution of your program and examine the program state.

It does not make much sense to go into details with debugging before you have learned the Visual Prolog language. But I will briefly explain the debugger anyway, because it can be very useful for understanding and experimenting with the language.

To start the debugger, select '''Debug -> Run''' in the menu. If the project is not up-to-date it will first be build, after that the debugging session will start.

'''Notice''' you can stop the debugging at any time by selecting '''Debug -> Stop Debugging''' in the menu.

When debugging starts the IDE will first load the debug information and then it will enter the program. The program execution is stopped just before the goal is executed. To indicate this, the goal is opened in an editor window, and the blue arrow points to the goal:

[[Image:tut01_debug1.png|Editor: Current Position]]

You can single step in the program using the '''Step Into '''and '''Step Over''' commands in the '''Debug '''menu.

Try '''Step Into''': this will open another editor with the code of mainExe::run, and the arrow will point to the entry of this code.

In the view menu you can open various debugger windows, which I will briefly explain.

The '''Run Stack''' window:

[[Image:tut01_runStack.png|Run Stack]]

contains a "picture" of the run stack. Exactly what you see depends on your settings in '''Tools -> Options... -> Debugger'''. In principle, the run stack contains a number of lines corresponding to calls that has been made. However, optimization (so called last call optimization) might have removed some entries.

The run stack not only shows the calls, it also shows trap points and backtrack points, these is described in a later tutorial and there I also describe the run stack window in more details.

The '''Local Variables''' window:

[[Image:tut01_localVariables.png|Local Variables]]

contains the local variables corresponding to the selection in the run stack window. Some variables might not yet have received a value, these are show as an underscore (i.e. like originalraiser in the above picture).

The '''Facts''' window:

[[Image:tut01_factsWindow.png|Facts]]

Contains the global state of the program, this state is stored in fact databases. ''Fact databases ''are a unique Visual Prolog feature, which will be described in a later tutorial. You can also add objects from the '''Local Variables '''window to the '''Facts''' window, that way you can track the state changes in interesting objects.

The '''Breakpoints '''window:

[[Image:tut01_breakPointsWindow.png]]

shows the current breakpoints in the program (I have set open breakpoint so that the window would not be empty). You can set/remove breakpoints by selecting '''Debug -> Toggle Breakpoint'''.

The remaining debug windows are for low level debugging and will not be considered here.

==Summary==

The Integrated Development Environment (IDE) makes it possible for you to:

*create

*build

*maintain, and

*debug

your projects. It contains a number of tools, editor and wizards that will help you in your tasks.

[[ru:Среда_разработки]]
[[Category:Tutorials]]

File:FundamentalVisualPrologData 03.png

2013-09-17T16:40:25Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologData 03.png"

Fundamental Visual Prolog - the Data Layer 03

{{Tutorial Image}}

File:FundamentalVisualPrologData 04.png

2013-09-17T16:39:08Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologData 04.png"

Fundamental Visual Prolog - the Data Layer 04

{{Tutorial Image}}

File:FundamentalVisualPrologData 02.png

2013-09-17T16:38:28Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologData 02.png"

Fundamental Visual Prolog - the Data Layer 02

{{Tutorial Image}}

File:FundamentalVisualPrologData 01.png

2013-09-17T16:37:39Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologData 01.png"

Fundamental Visual Prolog - the Data Layer 01

{{Tutorial Image}}

Fundamental Visual Prolog - the Business Logical Layer

2013-09-17T16:18:37Z

Gukalov: /* Connecting the Business Logic Layer to the GUI */

{{FundamentalPrologNavbar}}

In this tutorial, we shall modify the earlier simple '''GUI''' (Graphical User Interface) front end to the family tutorial which was developed in the tutorial "Fundamental Visual Prolog - GUI". We shall isolate the logic of the code from the rest of the '''GUI''' code. This logic would be reposed into an object belonging to its own package. We shall see that this method of isolating the code would enable us to clearly think about the logical issues separately from that of the '''GUI'''.

'''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/family3.zip Visual Prolog 7.2 version].
* [http://download.pdc.dk/vip/71/tutorial/family3.zip Visual Prolog 7.1 version].

==Initial Preparations==

In this tutorial, you would need to setup the project's '''GUI''' exactly as explained in the "Fundamental Visual Prolog - GUI" tutorial in a series of sequential steps before the section titled "Getting the Main Code into the Program". We shall assume that you have performed those '''GUI''' construction procedures correctly, and hence they are not repeated here.

'''Important:''' We are also assuming that you have created the AncestorDialog dialog in the '''GUI''' and given the code, so that that module has defined a predicate called getName to retrieve the name of the ancestor entered in that dialog.

We will assume that the project is entitled '''family3'''.

The '''GUI''' of the program is technically known as the presentation layer'''.''' Earlier, the code for the logic was intermingled within that presentation layer. Now, we shall take that logic and put it into its own package within the project. That package would act as a business logic layer.

Note that we are using the phrase ''"business logic"'' instead of merely the ''"logic"'', because it indicates the program's '''business''' side. In short, the raison-de-etre of the programis taken care of by that layer.

As Visual Prolog is a strongly object-oriented language, the business logic would now be represented by an object. This tutorial cannot get into all the details of object oriented programming present in Visual Prolog. They are separately explained in the tutorial "Introduction to Classes and Objects" and you are requested to read that tutorial for details. However, for completeness sake, some ideas regarding object-oriented would be mentioned in this tutorial also, wherever relevant. But before all that, let us complete the program in a step-by-step fashion.

==Creating the Business Logic Layer==

Once you have setup the '''GUI''' of the '''family3''' project, the main project tree would look something like this:

:[[Image:FundamentalVisualPrologBusiness_fig1.png]]

Now right click at the top of the tree and from the menu that is presented click on the New item as shown below:

:[[Image:FundamentalVisualPrologBusiness_fig2.png]]

From the Create Project Item dialog that is presented, select Package (the first item in the list on the left hand side) and give the name of the package as '''familyBLL''' (as a mnemonic for ''Family Business Logic Layer''; you should ideally choose something which is meaningful).

:[[Image:FundamentalVisualPrologBusiness_fig3.png]]

On clicking Create the project tree will now look like this:

:[[Image:FundamentalVisualPrologBusiness_fig4.png]]

If you now take a peep into the folder on your hard-disk, where these files are stored, you would notice that the IDE has created a separate folder (called familyBLL) within the main project folder to store all the files of this particular package.

Now, build the project to ensure that everything is in order.

==Working on the Business Logic Layer==

Let us now put the logic in place. We shall create and design a familyBL class in the familyBLL package to take full advantage of the object-oriented features of Visual Prolog. In this particular tutorial, not all the features are demonstrable. However, we shall be using one of the main features of an object-oriented system; namely that of data encapsulation. (Complete details on object-oriented features of Visual Prolog are available in the "Introduction to Classes and Objects" tutorial).

The term data encapsulation represents hiding the data within the code of a particular module in such a manner that it is not directly available for reading or modification from other modules of the program. Data access is strictly regulated and is indirectly available for reading and modifications through predicates of the class.

This concept avoids one of the most commonest programming errors seen in many programming languages. When data are kept lying around (metaphorically) for all programmers working on the project to read or write; it often becomes too tempting for programmers to write quick 'n dirty code to access and modify such data. This can be problematic especially in asynchronous programs such as '''GUI''' programs, where data can change unpredictably; often as per the behavior of the people using the program.

Another advantage of data encapsulation is that internal data representation systems can often be modified within a class, without the rest of the code in the project getting affected.

==Creating the Business Logic Class==

In the Project Tree, right click on the familyBLL package folder. From the menu that opens up, click on '''New''', as seen below:

:[[Image:FundamentalVisualPrologBusiness_fig5.png]]

From the Create Project Item dialog that is presented, create a class called '''familyBL'''. Ensure that the Creates Objects check box is switched on, as seen below:

:[[Image:FundamentalVisualPrologBusiness_fig6.png]]

The moment you click on the '''Create''' button, the IDE will present the '''familyBL.pro''' file to you for editing. Replace the default code from implement to end implement to the following:

<vip>implement familyBL
open core

facts
fileName : string.
clauses
new(Filename) :-
filename := Filename,
file::consult(Filename, familyDB).

clauses
save() :-
file::save(filename, familyDB).

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

clauses
father(Person, Father) :-
parent(Person, Father),
person(Father, male()).

clauses
grandfather(Person, Grandfather) :-
parent(Person, Parent),
father(Parent, Grandfather).

clauses
ancestor(Person, Ancestor) :-
parent(Person, Ancestor).
ancestor(Person, Ancestor) :-
parent(Person, P1),
ancestor(P1, Ancestor).

end implement</vip>

Now, click on the IDE File|Open menu item, open the file familyBL.i, and change the default code seen there with this:

<vip>interface familyBL
open core

domains
gender = female(); male().

predicates
father : (string Person, string Father) nondeterm (o,o) (i,o).

predicates
grandFather : (string Person, string Grandfather) nondeterm (o,o) .

predicates
ancestor : (string Person, string Ancestor) nondeterm (i,o).

predicates
save: ().

end interface</vip>

One more file automatically created by the IDE requires to be modified. Click on the File|Open file menu item in the IDE, and open the familyBL.cl file.

Before the predicates section you see in that file, you would need to insert the following code:

<vip>constructors
new : (string Filename).</vip>

After inserting the above code, the file will look like this:

:[[Image:FundamentalVisualPrologBusiness_fig7.png]]

Now build the project and check if everything is okay. It should be, and at this point, even though the code is in place, the project would technically compile into an empty project as we have not put in the ''glue'' to connect the '''GUI''' to the business logic layer. But before that, let us understand why the code for the familyBL class was put into three different files.

==Understanding the Business Logic Class==

If you compare the code that we have written so far with that we wrote in the earlier tutorial, you may arrive at these conclusions:

*The code was broken up into three sections.
*Some predicates and domains were declared in the .i file.
*All implementations were put inside the .pro file.
*The .cl file contained the declaration of a special kind of predicate called a constructor.

When we asked the IDE to create a class for us, we indicated that the class would generate ''objects''. It is important to differentiate the difference between a class and an object.

Metaphorically, a class could be looked upon as a cafeteria that gives out packaged pizzas. Just having such a cafeteria would not ensure that there would be pizzas coming out! One would need to explicitly ''instruct'' the cafeteria to send out the pizzas.

Just like the cafeteria, which has the capability of creating pizzas, a class has the capability of creating objects. An ''object'' contains ''code'' and'' data'' that is put together as per the implementation found in the class. Hence the class is analogous to the cafeteria. It can produce the objects. But not just yet!

Just because a class was coded in the project; it does not automatically imply that the project would automatically contain objects of that class. In every class, which is designed to generate objects, there would have to be one or more special constructor/s, which will construct a prepackaged object containing all the relevant code and data for working with the object.

Please note that Visual Prolog also allows creation of classes that does not generate objects, and the code within those classes mainly serve the purpose of modularization. This tutorial is not the right place for discussing such classes that do not create objects.

The constructors of a class are written in the .cl file of the said class. Predicates that are publicly accessible to the entire class as a whole (as opposed to the objects that the class can create) will also be present in that file. This can be seen in the utility predicate called classInfo, which is also declared in that file.

Each object that is created would require to have some publicly accessible predicates to manipulate the data which is encapsulated within it. Such predicates are declared separately in the .i file of the relevant class.

Finally, the implementation file (.pro extension) will contain the actual code. For all practical purposes, none of that code would really be seen by the other modules.

All this work may seem a little laborious. In fact, usually, the opposite is true: the clear cut manner, in which object-oriented programming has been implemented in Visual Prolog, can easily be put to use practically. For example, it is often a good strategy to assign different packages to different programmers, who would stitch up a complex project together with the minimum amount of hurdles, using object-oriented methodologies.

Now having understood all of that, we have to remember one important thing: the project still does not do anything useful simply because the '''GUI''' is not connected to the business logic layer. We shall now proceed to rectify that hurdle.

==Connecting the Business Logic Layer to the GUI==

In the Project Tree, right-click on the TaskWindow.win entry, and select '''Open''' as shown below.

:[[Image:FundamentalVisualPrologBusiness_fig8.png]]

In the Code Expert dialog, ensure that default handlers for the id_file_open, id_Query_father, id_Query_grand_father, id_Query_ancestor_of menu items are set, as seen below:

:[[Image:FundamentalVisualPrologBusiness_fig9.png]]

The event handler for id_file_exit for exiting the application correctly would have already been set by the IDE, so you do not have to set it again.

Before we populate the event handlers with the correct code, the presentation layer should contain one fact that will be used to store the object that the program is handling at any point in time.

Hence in the TaskWindow.pro file, the following code must be given:

<vip>facts
familyBL_db : (familyBL BL) determ.</vip>

The above fact will contain the object representing the family's business logic layer.

For the id_file_open menu item event handler give the following code:

<vip>clauses
onFileOpen(_Source, _MenuTag) :-
Filename = vpiCommonDialogs::getFileName("*.txt",
["Family data files (*.txt)","*.txt",
"All files", "*.*"],
"Load family database",
[], ".", _),
!,
BL = familyBL::new(Filename),
retractAll(familyBL_db(_)),
assert(familyBL_db(BL)),
stdio::writef("Database % loaded\n", Filename).
onFileOpen(_Source, _MenuTag).</vip>

Before we write the other event handlers, we need to insert a utility predicate as shown below:

<vip>predicates
tryGetFamilyBL : () -> familyBL BL determ.
clauses
tryGetFamilyBL() = BL :-
familyBL_db(BL),
!.
tryGetFamilyBL() = _ :-
stdio::write("No family database loaded\n"),
fail.</vip>

The above utility predicate is needed for gracefully handling situations, where the user may be attempting to query the family database before the database itself is loaded into the program. As we had indicated in an earlier tutorial, a '''GUI''' allows usage of the program as per the user's directions. The sequence of events that the user may undertake can never be fully known by the programmer. In fact, it is a good practice to allow the user to decide what set of activities is to be carried out in a '''GUI''' program.

As the program developed in this tutorial also adheres to such an approach, in our little program it is impossible to be really sure whether the user did load the database or not, when the querying is being done. There is always the possibility that the database was not loaded. Hence the program is instructed to use the above utility predicate for giving a graceful message to the user in the case there was no database loaded into the memory.

Now let us concentrate on the rest of the event handlers.

For the id_Query_Father menu item, the following event handler is to be given:

<vip>clauses
onQueryFather(_Source, _MenuTag) :-
stdio::write("\nfather test\n"),
foreach BL = tryGetFamilyBL(), BL:father(X,Y) do
stdio::writef("% is the father of %\n", Y, X)
end foreach.</vip>

For the id_Query_Grand_Father menu item, the following event handler code is to be given:

<vip>clauses
onQueryGrandFather(_MenuTag) = handled(0) :-
stdio::write("\ngrandFather test\n"),
foreach BL = tryGetFamilyBL(), BL:grandfather(X, Y) do
stdio::writef("% is the grandfather of %\n", Y, X)
end foreach.</vip>

And lastly, for the id_Query_Ancestor'','' the following event handler code is to be given:

<vip>clauses
onQueryAncestorOf(_Source, _MenuTag) :-
X = ancestorDialog::getName(thisWin),
stdio::writef("\nancestor of % test\n", X),
foreach BL = tryGetFamilyBL(), BL:ancestor(X, Y) do
stdio::writef("% is the ancestor of %\n", Y, X)
end foreach.</vip>

If you notice, all the above three event handlers attempts to retrieve the object under consideration using the tryGetFamilyBL() utility predicate, instead of directly accessing the facts section. In the case the database was not loaded, the utility predicate will fail after giving a graceful message in the Messages window.

==Understanding the Listeners==

If you examine the event handlers that we have now developed, and compare them with those which were developed in the '''GUI''' tutorial, you would notice that there are only small differences.

The most significant one is in the first event handler (onFileOpen) where the program constructs a new object of the program's business layer class and stores that object into the facts section of the module.

Another key point to be noted is the use of publicly accessible methods of the business layer object, which has been stored in the facts section of TaskWindow.pro module.

For example, in the following code snippet, the program retrieves a business logic layer object, signified by the variable BL, and then executes the publicly accessible predicate called grandfather of that object.

<vip>clauses
....
foreach BL = tryGetFamilyBL(), BL:grandfather(X, Y) do
stdio::writef("% is the grandfather of %\n", Y, X)
end foreach.</vip>

The colon operator "''':'''" between the variable and the predicate is an indicator of that logic. The colon operator which retrieves the publicly accessible predicate of an object is different from the double-colon operator "::", which retrieves a publicly accessible predicate of the entire class. This is seen in the stdio::writef(...) predicate call in the above code snippet. Note that the double-colon operator cannot be used on objects and neither can the colon operator be used on classes.

==Running the Code==

At this point, we can now compile and run the program. If there are any errors, then I would request you to re-read this code and maybe the earlier tutorial also and check for any errors in your program. One point to be noted is that while setting the event handlers, do ''not'' change an event handler name for the event for which a hander was ''already'' set earlier.

When you run this program, you would notice that the program functions exactly in the same manner as before. This is one of the fundamental beauties of object oriented programming: it allows quite a lot of internal coding changes without the final functionality changing.

==Some More Details==

In this system of object-oriented programming class facts are changed into object facts, as each object would encapsulate its own facts.

Let us use once again the cafeteria example and make an analogy of ''facts'' with the pizza toppings. This situation is therefore like stating that the toppings on each pizza would be dispatched along with each individual pizza. The toppings would not be left behind at the cafeteria else all the customers would have to come back to the cafeteria to use the toppings! Fortunately, it does make more sense to send the toppings along with the pizza. So is the case with object-oriented programming. It often makes sense to package the facts into the ''objects'' of a class rather than put the facts into the class itself.

When we use objects to represent the data, the maintenance of the data becomes much easier. If we do not use an object-oriented approach we may require to clean up the remnants of the earlier data by using the retract predicate (retract is a built-in predicate of Visual Prolog). However, retract is not needed now because a new object is created on load and the old object will be automatically removed by the program using a process called garbage-collection. This happens automatically in the background during some known safe conditions without affecting the user.

When declaring predicates the flows of the parameters to a predicate must be specifically added to predicate declarations, the way we did in the .i file. The anyflow flow-pattern cannot be used on global entities.

In the code implemented in the business layer, we had implemented a predicate for saving the data back to a file. If you note, the save predicate does not need a file name, because the file name is stored in the object. It is left as an exercise to you, to connect this functionality to some suitable '''GUI''' event handlers.

==Conclusions==

In this tutorial we learnt that a finer separation of business logic and its data from the presentation (i.e. '''GUI''') is not only possible but is strongly recommended. Visual Prolog can intelligently assist us create a package containing all the classes that are needed to manage this separation. In this particular tutorial, one class was developed in the package, which achieved this objective. Such a class could create objects that encapsulated both the data and business logic. Other modules are able to function only on a need-to-know basis regarding the business logic layer using such objects. This makes the maintenance and modular development of software much more easier and less error prone.

==References==

[[Category:Fundamental Visual Prolog Tutorial]]

File:FundamentalVisualPrologBusiness fig8.png

2013-09-17T16:07:37Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig8.png"

Fundamental Visual Prolog - Business 08

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig9.png

2013-09-17T16:03:24Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig9.png"

Fundamental Visual Prolog - Business 09

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig6.png

2013-09-17T15:35:34Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig6.png"

Fundamental Visual Prolog - Business 06

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig5.png

2013-09-17T15:34:21Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig5.png"

Fundamental Visual Prolog - Business 05

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig4.png

2013-09-17T15:29:18Z

Gukalov:

File:FundamentalVisualPrologBusiness fig1.png

2013-09-17T15:28:08Z

Gukalov:

File:FundamentalVisualPrologBusiness fig3.png

2013-09-17T15:18:26Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig3.png"

Fundamental Visual Prolog - Business 03

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig2.png

2013-09-17T15:17:19Z

Gukalov: uploaded a new version of "Image:FundamentalVisualPrologBusiness fig2.png"

Fundamental Visual Prolog - Business 02

{{Tutorial Image}}

File:FundamentalVisualProlog8.png

2013-09-17T06:57:39Z

Gukalov: uploaded a new version of "Image:FundamentalVisualProlog8.png"

Fundamental Visual Prolog

2013-09-17T06:55:29Z

Gukalov: /* Step 4: Rebuild the Code */

{{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 executable file family1.exe 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]]