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

Category:VpPuZzle

2009-11-28T08:55:15Z

Kari Rastas: spelling error corrected

{{spbCopyright}}

VpPuZzle is set of agreements to build VIP-based applications on the basis of the standard VIP packages placed into DLLs. The VIP package fitted to PZL-technology agreements is named pzl-Component . The VIP project (executable or DLL), which contains pzlComponents, organized in a special way, is named pzl-Container . The pzl-container, which is the DLL, is named dll-container.
The VpPuZzle is created to work with the Visual Prolog 7.1 and above.
You need the only minimal knowledge in Visual Prolog programming system to [[Pzl-Component in 10 steps|''create and run the pzl-component'']].

The pzl-technology includes:
*The set of statically linked libraries, which support the pzl-system run
*Classes, which support the communication with the Pzl-system
*The Elementary PzlStudio application, which gives the possibility
**to include the pzl-system into any application created in Visual Prolog.
**To create the dll-containers
**To create pzl-components and put them into the pzl-containers
**to perform other activities, which support the development process.

=The Information regarding the pzl-technology=
The general concept, which is the basis of the Pzl-technology, described in '''[[VpPuZzle. Observe. Part 1|VpPuZzle. Observe]]'''

The agreements, which pzl-Components must fit, described in the manual '''[[Pzl-Component]]'''.

The programmer may communicate with the Pzl-system by means of predicates of classes, which are described in:
*'''[[Class PzlPort]]'''
*'''[[Class Pzl]]'''

The description of the Elementary PzlStudio placed to the document '''[[Elementary PzlStudio]]'''. Parts of this document may be found also separately.

=The example of the building the Pzl-container and the Pzl-Component=

In the document [[Pzl-Component in 10 steps|''"Pzl-Component in 10 steps"'']] it is described in details how to build the Dll-container ''MyDemoContainer'' and the Dll-Component ''MyHelloWorld'' together with the demonstration of the run directly from the development environment ''Elementary PzlStudio'''''.

To run this example you need to install the appropriate set of tools related to pzl-technology.

Class PzlPort

2009-11-28T08:53:35Z

Kari Rastas: spelling errors corrected

{{spbCopyright}}

'''package PzlPort'''

The class pzlPort is the core of the VpPuzzle system and supports the use of pzl-components. This class must be included to the project, which generates the main executable application(.EXE).

The calls of the predicates of the class PzlPort are possible only from the classes of the main executable application project. Components placed to the dll-containers can not make a calls of the predicats of the class PzlPort.

=Predicate summary=
{|cellspacing="0" border="1" style="float:center;background:#F9F9F9;color:black;"
|-
|[[#core::classInfo/0|classInfo]].
get the information regarding the class
|-
|[[#pzlPort::init/0|init:()]].
Initialization of the VpPuZzle system
|-
|[[#pzlPort::setComponentRegisterFileName/1|setComponentRegisterFileName:(string ComponentRegisterFileName)]].
Set the name of the component registry file
|-
|[[#pzlPort::isInitialized/0|isInitialized:() determ]].
Checking of the initialization status of the VpPuZzle system
|}

=Additionally used resources=
The mandatory use:
*the pzlPort_XX.lib library must be used, where XX - license qualifier. The library in fact contains the implementation of the class PzlPort and also the library includes the implementation of the handling of the pzl-container of the main executable application.
*the package pzlConfig must be used. The package PzlConfig participates in the initialization procedure.

=Predicate details=
==core::classInfo/0==
{{predicate
|decl=
<vip>classInfo:().</vip>
|short=
get the information regarding the class
|full=
The predicate is the tipical predicate, which is generated when any class generated automatically by the IDE of the Visual Prolog System
}}
==pzlPort::init/0==
{{predicate
|decl=
<vip>init:().</vip>
|short=
Initialization of the VpPuZzle system
|full=
The predicate must be the first predicate, which is used while the accessing to the Pzl-system. It must be called only once. After initialization the calls to other classes of the Pzl system become possible.

The initialization of the pzl-system may be performed immediately after the main application start. It also may be performed at any moment when the pzl-system is expected to be used.
The de-initialization of the pzl-system is impossible.

The repetitions of the initialization are ignored.
|example=
<vip>
clauses
run():-
pzlPort::init(),
TaskWindow = taskWindow::new(),
...
</vip>
}}
==pzlPort::setComponentRegisterFileName/1==
{{predicate
|decl=
<vip>setComponentRegisterFileName:(string ComponentRegisterFileName).</vip>
|short=
Set the name of the component registry file
|full=
The file ComponentRegisterFileName is one of the places, where the information regarding the pzl-components at the given computer is stored. The other place of store is the Windows registry. When the searching process runs the component registry file is used first. If the file doesn't exist or the component is not registered there, then the search process continued in the Windows registry.

The information in the component registry file is stored in the Visual Prolog term format (save-consult data format). Before the component may be used at the given computer, it must be registered at this computer. The application, which uses the pzl-technology may avoid the use of the component registry file or the application may assign the use of the file by using the predicate setComponentRegisterFileName/1.

The parameter ''ComponentRegisterFileName'' must be the full path to the file, or it may be relative to the directory, where the main application is placed.
The file extension is not strongly defined in the pzl-system. The recommended file extension is - '''.PZR'''.

The component registration file of the application may be assigned only once. While the repetitive assignment the existence of the previous assignment is not checked.

The component registration data is load only once while the first access to an any pzl-component. Thus the second (and further) file assignment is not make influence on the component registration.

The content validation of the file ''ComponentRegisterFileName'' while the predicate '''''setComponentRegisterFileName''''' performing is not used. But the file must exist.

It is possible to get the name of the component registration file, assigned at the pzl-system by the use of the predicate call <vip>RegistryFileStatus=pzl::getComponentRegisterFileName()</vip> The predicate pzl::getComponentRegisterFileName() returns the term, which reflects the status of the assignment of the file. If the file name has been assigned successfully, then the name will be returned as the parameter of the term.
|except=
If there is no file with the given name ''ComponentRegisterFileName'', then the exception is generated with the text
<vip>"The file <ComponentRegisterFileName> can not be found"</vip>
While checking the file existence the system exception are possible and they are stored with the message <vip>"System Error while checking the file <ComponentRegisterFileName> existence"</vip>
The error code will be stored also.
|example=
<vip>
class predicates
runProfile:(window TaskWindow,string RegistryFileName,string InitialComponent).
clauses
runProfile(_TaskWindow,RegistryFileName,_InitialComponent):-
not(RegistryFileName=""),
trap(pzlPort::setComponentRegisterFileName(RegistryFileName),_Err,fail()),
fail.
runProfile(TaskWindow,RegistryFileName,InitialComponent):-
RegistryFileStatus=pzl::getComponentRegisterFileName(),
notifyUser(TaskWindow,RegistryFileStatus,RegistryFileName),
runStudioStarter(TaskWindow,InitialComponent).
</vip>
}}

==pzlPort::isInitialized/0==
{{predicate
|decl=
<vip>isInitialized:() determ.</vip>
|short=
Checking of the initialization status of the VpPuZzle system
|full=
Makes it possible to check whether the initialization of the pzl-system was performed. If the result of the check is positive, then predicate succeeds.
|example=
<vip>
clauses
run():-
not(isInitialazed()),
pzlPort::init(),
fail.
run():-
TaskWindow = taskWindow::new(),
...
</vip>
}}
=References=
[[Category:VpPuZzle]]

Class PzlPort

2009-11-28T08:49:57Z

Kari Rastas: /* pzlPort::setComponentRegisterFileName/1 */ some spelling errors corrected

{{spbCopyright}}

'''package PzlPort'''

The class pzlPort is the core of the VpPuzzle system and supports the use of pzl-components. This class must be included to the project, which generates the main executable applicaion(.EXE).

The calls of the predicates of the class PzlPort are possible only from the classes of the main executable applicaion project. Components placed to the dll-containers can not make a calls of the predicats of the class PzlPort.

=Predicate summary=
{|cellspacing="0" border="1" style="float:center;background:#F9F9F9;color:black;"
|-
|[[#core::classInfo/0|classInfo]].
get the information regarding the class
|-
|[[#pzlPort::init/0|init:()]].
Initialization of the VpPuZzle system
|-
|[[#pzlPort::setComponentRegisterFileName/1|setComponentRegisterFileName:(string ComponentRegisterFileName)]].
Set the name of the component registry file
|-
|[[#pzlPort::isInitialized/0|isInitialized:() determ]].
Checking of the initialization status of the VpPuZzle system
|}

=Additionally used resources=
The mandatory use:
*the pzlPort_XX.lib library must be used, where XX - license qualifier. The library in fact contains the implementation of the class PzlPort and also the library includes the implementation of the handling of the pzl-container of the main executable application.
*the package pzlConfig must be used. The package PzlConfig participates in the initialization procedure.

=Predicate details=
==core::classInfo/0==
{{predicate
|decl=
<vip>classInfo:().</vip>
|short=
get the information regarding the class
|full=
The predicate is the tipical predicate, which is generated when any class generated automatically by the IDE of the Visual Prolog System
}}
==pzlPort::init/0==
{{predicate
|decl=
<vip>init:().</vip>
|short=
Initialization of the VpPuZzle system
|full=
The predicate must be the first predicate, which is used while the accessing to the Pzl-system. It must be called only once. After initialization the calls to other classes of the Pzl system become possible.

The initialization of the pzl-system may be performed immidiately after the main applicaion start. It also may be performed at any moment when the pzl-system is expected to be used.
The deinitialization of the pzl-system is impossible.

The repetitions of the initialization are ignored.
|example=
<vip>
clauses
run():-
pzlPort::init(),
TaskWindow = taskWindow::new(),
...
</vip>
}}
==pzlPort::setComponentRegisterFileName/1==
{{predicate
|decl=
<vip>setComponentRegisterFileName:(string ComponentRegisterFileName).</vip>
|short=
Set the name of the component registry file
|full=
The file ComponentRegisterFileName is one of the places, where the information regarding the pzl-components at the given computer is stored. The other place of store is the Windows registry. When the searching process runs the component registry file is used first. If the file doesn't exist or the component is not registered there, then the search process continued in the Windows registry.

The information in the component registry file is stored in the Visual Prolog term format (save-consult data format). Before the component may be used at the given computer, it must be registered at this computer. The application, which uses the pzl-technology may avoid the use of the component registry file or the application may assign the use of the file by using the predicate setComponentRegisterFileName/1.

The parameter ''ComponentRegisterFileName'' must be the full path to the file, or it may be relative to the directory, where the main application is placed.
The file extension is not strongly defined in the pzl-system. The recommended file extension is - '''.PZR'''.

The component registration file of the application may be assigned only once. While the repetitive assignment the existence of the previous assignment is not checked.

The component registration data is load only once while the first access to an any pzl-component. Thus the second (and further) file assignment is not make influence on the component registration.

The content validation of the file ''ComponentRegisterFileName'' while the predicate '''''setComponentRegisterFileName''''' performing is not used. But the file must exist.

It is possible to get the name of the component registration file, assigned at the pzl-system by the use of the predicate call <vip>RegistryFileStatus=pzl::getComponentRegisterFileName()</vip> The predicate pzl::getComponentRegisterFileName() returns the term, which reflects the status of the assignment of the file. If the file name has been assigned successfully, then the name will be returned as the parameter of the term.
|except=
If there is no file with the given name ''ComponentRegisterFileName'', then the exception is genereated with the text
<vip>"The file <ComponentRegisterFileName> can not be found"</vip>
While checking the file existence the system exception are possible and they are stored with the message <vip>"System Error while checking the file <ComponentRegisterFileName> existence"</vip>
The error code will be stored also.
|example=
<vip>
class predicates
runProfile:(window TaskWindow,string RegistryFileName,string InitialComponent).
clauses
runProfile(_TaskWindow,RegistryFileName,_InitialComponent):-
not(RegistryFileName=""),
trap(pzlPort::setComponentRegisterFileName(RegistryFileName),_Err,fail()),
fail.
runProfile(TaskWindow,RegistryFileName,InitialComponent):-
RegistryFileStatus=pzl::getComponentRegisterFileName(),
notifyUser(TaskWindow,RegistryFileStatus,RegistryFileName),
runStudioStarter(TaskWindow,InitialComponent).
</vip>
}}

==pzlPort::isInitialized/0==
{{predicate
|decl=
<vip>isInitialized:() determ.</vip>
|short=
Checking of the initialization status of the VpPuZzle system
|full=
Makes it possible to check whether the initialization of the pzl-system was performed. If the result of the check is positive, then predicate succeeds.
|example=
<vip>
clauses
run():-
not(isInitialazed()),
pzlPort::init(),
fail.
run():-
TaskWindow = taskWindow::new(),
...
</vip>
}}
=References=
[[Category:VpPuZzle]]

3rd:Main Page

2009-05-11T06:52:34Z

Kari Rastas: spelling error

The namespace '''3rd''' is dedicated to descriptions of 3rd party packages, add-on's, applications, etc, which are available to fellow programmers.

Articles are in the '''3rd''' namespace if the title has this format: '''3rd:<title>'''.

It is advantageous, if you give your package/add-on/... a '''name''', and then use '''3rd:<name>''' as article title. (The name can have several words).

Remember to write:
* How to obtain the package/add-on/...
* Which license conditions that applies
* Whether the package/add-on/... is free or not

Also check-out http://www.arsaniit.com/prolog-tools

=== Contents ===

* [[3rd:QDBM|QDBM]] a key->value database (GNU license).
* [[3rd:Scintilla Editor Control|Scintilla Editor Control]] custom control wraps the scintilla editor.
* [[3rd:SCS - Simple Client Server|SCS - Simple Client Server]] a package for creating client server solutions.
* [[3rd:VPcURL|VPcURL]] provides Visual Prolog bindings to the cURL library, which is a library for HTTP and FTP.
* [[3rd:Tools & Support|Tools & Support]] is an article about useful non-Visual Prolog tools and support sites.
* [[3rd:RS232|RS232]] packages for communicating via the RS232-interface of a computer.
* [[3rd:Fast Articifial Neural Networks (FANN)|Fast Articifial Neural Networks (FANN)]] bindings to the FANN library.
* [[3rd:VIC - VIP7 IDE companion]] VIC provides 2 major tools, and a few little utilities, to help with the development of VIP7 projects.

Talk:CGI Applications in Visual Prolog

2008-07-14T14:05:54Z

Kari Rastas: missing example program download link in the CGI tutorials

Seems that the download link of the examples is missing (or at least I did not manage to locate it).

I would be "good" if the downloads of the examples and tutorials would be presented in a "standardized" way. Either in the beginning or end, same place in all, and made better recognizable with some "good-looking" image.

3rd:QDBM

2008-01-09T08:04:45Z

Kari Rastas: The article uses often the term I (writer) so the writers name is needed or the article has to be changed in a non personal "mode"

Written by Gildas Menier.

For the management of key->values in Visual Prolog, you may use factsDB, chainDB or some sql based solution. Each solution has benefits and drawbacks. For some reasons, I had to find another solution.

Mikio Hirabayashi has built a very nice API called 'QDBM'.

http://qdbm.sourceforge.net/

see also http://qdbm.sourceforge.net/benchmark.pdf

QDBM is well known in the Unix world, but has been ported to Win32. Practically, it is a disk-based Hashtable + Binary tree + inverted list package. QDBM offers many solutions called 'depot', 'curia', 'villa', 'odeum' and is well worth a look if you want to manage large amount of data.

In the enclosed project, you'll find a small 'depot' wrapper for Visual Prolog.

The example creates 1.000.000 (key, values) and then ask for 1.000.000 keys at random. All the key/values are stored on disk in a single file.

Using a collection of instances of the visual prolog class 'depot', you can manage a very large hashtable on disk.

I do not provide a full documentation since the real documentation can be found on the above web site. Only the port of depot is functional in this lib.

I tried to simplify the use of this lib as much as possible, and tried not to get too far away from the original API syntax:

<vip>NewDepot = depot::new("dtest"), % create a depot db
NewDepot:dbopen("create"), % open it (create mode)
NewDepot:dbput_string(Key, Value), % put a key,value
NewDepot:dbclose(), % close the file</vip>

and you can access the db as follows:

<vip>ReadDepot = depot::new("dtest"), %
ReadDepot:dbopen("read"), % open it in read mode
Value = ReadDepot:dbget_string(Key), % tries to find the value for a key, fails if no value
ReadDepot:dbclose(), %</vip>

More predicates are provided. Please, have a look on the documentation of QDBM/depot and on the depot.pro file.

The project doesn't include a copy of qdbm (because of the allowed posting size); I encourage you to download the most up-to-date version on the site above. It is provided under the GNU Lesser GPL.
Just copy the three following files into your exe directory:

* libiconv-2.dll
* mgwz.dll
* qdbm.dll

you will find the package there:

http://qdbm.sourceforge.net/win/

Example project/download in [http://discuss.visual-prolog.com/viewtopic.php?t=6594 Discussion forum: (how to) deal with large amounts of (key,value)]

Fundamental Visual Prolog

2007-11-21T06:18:38Z

Kari Rastas: /* Keywords */ bold

{{FundamentalVisualPrologNavbar}}

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 Part 2 of the "Fundamental Prolog" Tutorial.

==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 file. It is defined in some other file, 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.<img alt src="../tut11/images/tut11_dot.gif" border="0" width="1" height="1">

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. It has to be written into the file called ''family1.pro''. 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 family1
open core

constants
className = "family1".
classVersion = "$JustDate: $$Revision: $".

clauses
classInfo(className, classVersion).

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 anyflow.
clauses
grandFather(Person, GrandFather) :-
parent(Person, Parent),
father(Parent, GrandFather).

class predicates
ancestor : (string Person, string Ancestor) nondeterm anyflow.
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 family1

goal
mainExe::run(family1::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.

[[Image:FundamentalVisualProlog1.jpg]]

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

[[Image:FundamentalVisualProlog2.jpg]]

===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 family1.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 family1.pro (given in this tutorial) into that window.

[[Image:FundamentalVisualProlog5.jpg]]

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

[[Image:FundamentalVisualProlog6.jpg]]

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

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

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

Fundamental Visual Prolog

2007-11-20T17:13:51Z

Kari Rastas: /* Keywords */ added indentions

{{FundamentalVisualPrologNavbar}}

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 Part 2 of the "Fundamental Prolog" Tutorial.

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

<blockquote>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.</blockquote>

open

<blockquote>This keyword is used to extend the ''scope visibility'' of the class. It is to be used just after the implement keyword.</blockquote>

constants

<blockquote>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:

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

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.</blockquote>

domains

<blockquote>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.</blockquote>

class facts

<blockquote>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.</blockquote>

class predicates

<blockquote>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.</blockquote>

clauses

<blockquote>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.</blockquote>

goal

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

====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 file. It is defined in some other file, 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.<img alt src="../tut11/images/tut11_dot.gif" border="0" width="1" height="1">

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. It has to be written into the file called ''family1.pro''. 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 family1
open core

constants
className = "family1".
classVersion = "$JustDate: $$Revision: $".

clauses
classInfo(className, classVersion).

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 anyflow.
clauses
grandFather(Person, GrandFather) :-
parent(Person, Parent),
father(Parent, GrandFather).

class predicates
ancestor : (string Person, string Ancestor) nondeterm anyflow.
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 family1

goal
mainExe::run(family1::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.

[[Image:FundamentalVisualProlog1.jpg]]

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

[[Image:FundamentalVisualProlog2.jpg]]

===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 family1.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 family1.pro (given in this tutorial) into that window.

[[Image:FundamentalVisualProlog5.jpg]]

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

[[Image:FundamentalVisualProlog6.jpg]]

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

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

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

Compound and List Domains

2007-10-04T07:17:31Z

Kari Rastas:

In this tutorial we will introduce compound domains (sometimes called algebraic data structures). Compound domains are used to handle several pieces of data as a single entity. Lists is an example of compound domains. Lists are used so much that they have even received special syntactical sugaring.

Compound and list domains are created using built-in domains and other compound and list domains. Visual Prolog help describes built-in domains: integral, real, string, symbol, char, string8, pointer, binary, boolean, object.

==Compound Domains and Functors==

Compound domains allow you to treat several pieces of information as a single item in such a way that you can easily pick them apart again. Consider, for instance, the date "October 15, 2003". It consists of three pieces of information – the month, day, and year – but it is useful to treat the whole thing as a single data with a treelike structure:

<pre> DATE
/|\
/ | \
/ | \
/ | \
October 15 2003</pre>You can do this by declaring a domain containing the compound domain '''date''':

<vip>domains
date_cmp = date(string Month, unsigned Day, unsigned Year).</vip>

and then simply writing e.g.

<vip>D = date("October", 15, 2003),</vip>

This looks like a Prolog fact, but it isn't here – it is just a value, which you can handle in much the same way as a string or number. It begins with a name, usually called a functor(in this case date), followed by three arguments.

Note carefully that a functor in Visual Prolog has nothing to do with a function in other programming languages. '''''A functor does not stand for some computation to be performed.''''' it is just a name that identifies a kind of compound value and holds its arguments together.

The arguments of a compound value can themselves be compound. For instance, you might think of someone's birthday as an information structure like this:

<pre> birthday
/ \
/ \
/ \
/ \
/ \
person date
/ \ / | \
/ \ / | \
"Per" "Schultze" "Apr" 14 1960</pre>In Prolog you would write this as:

<vip>birthday(person("Per", "Schultze"), date("Apr",14,1960)).</vip>

In this example, there are two sub-parts in the compound birthday value: the argument person("Per", "Schultze") and the argument date("Apr", 14, 1960). The functors of these values are person and date.

==Unification of Compound Domains==

A compound value can unify either with a simple variable or with a compound value that matches it(perhaps containing variables as parts of its internal structure). This means you can use a compound value to pass the whole collection of items as a single value, and then use unification to pick them apart. For example,

<vip>date("April", 14, 1960)</vip>

matches X and binds X to date("April",14,1960). Also

<vip>date("April", 14, 1960)</vip>

matches date(Mo,Da,Yr) and binds Mo to "April", Da to 14, and Yr to 1960.

===Using the Equal Sign to Unify Compound Domains===

Visual Prolog performs unification in two places. The first is when a call or goal matches the head of a clause. The second is across the '''''equal'''''(=) sign, which is actually an infix predicate(a predicate that is located ''between'' its arguments rather than ''before'' them).

Visual Prolog will make the necessary bindings to unify the values on both sides of the '''''equal''''' sign. This is useful for finding the values of arguments within a compound value. For example, the following code excerpt tests if two people have the same last name, then gives the second person the same address as the first.

<vip>class my
domains
person = person(name, address).
name = name(string First, string Last).
address = addr(street, string City, string State).
street = street(integer Number, string Street_name).

predicates
run :().
end class

implement my
clauses
run():-
console::init(),
P1 = person(name("Jim", "Smith"),
addr(street(5, "1st st"), "igo", "CA")),
P1 = person(name(_, "Smith"), Address),
P2 = person(name("Jane", "Smith"), Address),
!,
stdio::write("P1 = ", P1, "\n"),
stdio::write("P2 = ", P2, "\n")
;
stdio::write("No solution").
end implement

goal
my::run.</vip>

==Treating Several Items as One==

Compound values can be regarded and treated as single values in your Prolog clauses, which greatly simplifies programming. Consider, for example, the fact

<vip>owns("John", book("From Here to Eternity", "James Jones")).</vip>

in which you state that John owns the book "From Here to Eternity", written by "James Jones". Likewise, you could write

<vip>owns("John", horse("Blacky")).</vip>

which can be interpreted as

John owns a horse named Blacky.

The compound values in these two examples are

<vip>book("From Here to Eternity", "James Jones")).</vip>

and

<vip>horse("Blacky").</vip>

If you had instead written two facts:

<vip>owns("John", "From Here to Eternity").
owns("John", "Blacky").</vip>

you would not have been able to decide whether Blacky was the title of a book or the name of a horse. On the other hand, you can use the first component of a compound value – the functor – to distinguish between different kinds of values. This example used the functors book and horse to indicate the difference between the values.

'''Remember''': Compound values consist of a functor and the arguments belonging to that functor, as follows:

<vip>functor(argument1, argument2, ..., argumentN)</vip>

===An Example Using Compound Domains===

An important feature of compound domains allows you to easily pass a group of values as one argument. Consider a case where you are keeping a telephone database. In your database, you want to include your friends' and family members' birthdays. Here is a section of code you might have come up with:

<vip>predicates
phone_list :(string First, string Last, string Phone, string Month, intege Day, integer Year) determ.

clauses
phone_list("Ed", "Willis", "422-0208", "aug", 3, 1955).
phone_list("Chris", "Grahm", "433-9906", "may", 12, 1962).</vip>

Examine the data, noticing the six arguments in the fact phone_list; five of these arguments can be broken down into two compound domains, like this:

<pre> person birthday
/ \ / | \
/ \ / | \
First Name Last Name Month Day Year</pre>It might be more useful to represent your facts so that they reflect these compound domains. Going back a step, you can see that person is a relationship, and the first and last names are the arguments. Also, birthday is a relationship with three arguments: month, day, and year. The Prolog representation of these relationships is

<vip>owns("John", "From Here to Eternity").
owns("John", "Blacky").</vip>

You can now rewrite your small database to include these compound domains as part of your database.

<vip>domains
name = person(string First, string Last).
birthday = b_date(string Month, integer Day, integer Year).

class predicates
phone_list :(name, string Ph_num, birthday) determ.
clauses
phone_list(person("Ed", "Willis"), "422-0208",
b_date("aug", 3, 1955)).
phone_list(person("Chris", "Grahm"), "433-9906",
b_date("may", 12, 1962)).</vip>

In this program, two compound '''domains''' declarations were introduced. We go into more detail about these compound data structures later in this chapter. For now, we will concentrate on the benefits of using such compound domains.

The phone_list predicate now contains three arguments, as opposed to the previous six. Sometimes breaking up your data into compound values will clarify your program and might help process the data.

Now add some rules to program. Suppose you want to create a list of people whose birthdays are in the current month. Here is the program code to accomplish this task; this program uses the standard predicate date to get the current date from the computer's internal clock. Predicate date will return the current year, month, and day from your computer's clock.

<vip>class my
domains
name = person(string First, string Last).
birthday = b_date(string Month, integer Day, integer Year).
predicates
phone_list :(name, string Ph_num, birthday) multi(o,o,o).
get_months_birthdays :().
convert_month :(string Name, integer Num) determ(i,o).
check_birthday_month :(integer Month_num, birthday) determ.
write_person :(name).
end class

implement my
clauses
get_months_birthdays() :-
stdio::write("****** This Month's Birthday List *****\n"),
stdio::write(" First Name\t\t Last Name\n"),
stdio::write("***********************************\n"),
CurTime = time::new(),
CurTime:getDate(_, ThisMonth, _),
phone_list(Person, _, Date),
check_birthday_month(ThisMonth, Date),
write_person(Person),
fail.
get_months_birthdays() :-
stdio::write("\n Press any key to continue:\n"),
_ = console::readChar().

clauses
write_person(person(FirstName, LastName)) :-
stdio::write(" ", FirstName, "\t\t ", LastName, "\n").

clauses
check_birthday_month(Mon, b_date(Month, _, _)) :-
convert_month(Month, Month1),
Mon = Month1.

clauses
phone_list(person("Ed", "Willis"), "11-1111", b_date("Jan", 3, 1955)).
phone_list(person("Benjamin", "Thomas"), "222-2222", b_date("Feb", 5, 1965)).
phone_list(person("Ray", "William"), "333-3333", b_date("Mar", 3, 1955)).
phone_list(person("Tomas", "Alfred"), "444-4444", b_date("Apr", 29, 1975)).
phone_list(person("Chris", "Gralm"), "555-5555", b_date("May", 12, 1975)).
phone_list(person("Dastin", "Robert"), "666-6666", b_date("Jun", 17, 1975)).
phone_list(person("Anna", "Friend"), "777-7777", b_date("Jul", 2, 1975)).
phone_list(person("Naomi", "Friend"), "888-8888", b_date("Aug", 10, 1975)).
phone_list(person("Christina", "Lynn"), "999-9999", b_date("Sep", 25, 1975)).
phone_list(person("Kathy", "Ann"), "110-1010", b_date("Oct", 20, 1975)).
phone_list(person("Elizabeth", "Ann"), "110-1111", b_date("Nov", 9, 1975)).
phone_list(person("Aaron", "Friend"), "110-1212", b_date("Dec", 31, 1975)).
phone_list(person("Jenifer", "Faitlin"), "888-8888", b_date("Aug", 14, 1975)).

clauses
convert_month("Jan", 1).
convert_month("Feb", 2).
convert_month("Mar", 3).
convert_month("Apr", 4).
convert_month("May", 5).
convert_month("Jun", 6).
convert_month("Jul", 7).
convert_month("Aug", 8).
convert_month("Sep", 9).
convert_month("Oct", 10).
convert_month("Nov", 11).
convert_month("Dec", 12).
end implement

goal
console::init(),
my::get_months_birthdays().</vip>

How do compound domains help in this program? This should be easy to see when you examine the code. Most of the processing goes on in the get_months_birthdays predicate.

*First, the program makes a window to display the results.

*After this, it writes a header in the window to help interpret the results.

*Next, in get_months_birthdays, the program uses the built-in predicate date to obtain the current month.

*After this, the program is all set to search the database and list the people who were born in the current month. The first thing to do is find the first person in the database. The call phone_list(Person, _, Date) binds the person's first and last names to the variable Person by binding the entire functor person to Person. It also binds the person's birthday to the variable Date.<br />
Notice that you only need to use one variable to store a person's complete name, and one variable to hold the birthday. This is the power of using compound domains.

*Your program can now pass around a person's birthday simply by passing on the variable Date. This happens in the next subgoal, where the program passes the current month(represented by an integer) and the birthday(of the person it is processing) to the predicate check_birthday_month.

*Look closely at what happens. Visual Prolog calls the predicate check_birthday_month with two variables: The first variable is bound to an integer, and the second is bound to a birthday term. In the head of the rule that defines check_birthday_month, the first argument, This_month, is matched with the variable Mon. The second argument, Date, is matched against b_date(Month, _,_).<br />
Since all you are concerned with is the month of a person's birthday, you have used the anonymous variable for both the day and the year of birth.

*The predicate check_birthday_month first converts the string for the month into an integer value. Once this is done, Visual Prolog can compare the value of the current month with the value of the person's birthday month. If this comparison succeeds, then the subgoal check_birthday_month succeeds, and processing can continue. If the comparison fails(the person currently being processed was not born in the current month), Visual Prolog begins to backtrack to look for another solution to the problem.

*The next subgoal to process is write_person. The person currently being processed has a birthday this month, so it is OK to print that person's name in the report. After printing the information, the clause fails, which forces backtracking.

*'''''Backtracking always goes up to the most recent non-deterministic call and tries to re-satisfy that call.''''' In this program, the last non-deterministic call processed is the call to phone_list. It is here that the program looks up another person to be processed. If there are no more people in the database to process, the current clause fails; Visual Prolog then attempts to satisfy this call by looking further down in the database. Since there is another clause that defines get_months_birthdays, Visual Prolog tries to satisfy the call to get_months_birthdays by satisfying the subgoals to this other clause.

==Declaring Compound Domains==

In this section, we show you how instances of compound domains are defined. After compiling a program that contains the following relationships:

<vip>owns("John", book("From Here to Eternity", "James Jones")).</vip>

and

<vip>owns("John", horse("Blacky")).</vip>

you could query the system with this goal:

<vip>owns("John", X))</vip>

The variable X can be bound to a different type: a book, a horse, or perhaps other types you define. Because of your definition of the owns predicate, you can no longer employ the old predicate declaration of owns:

<vip>owns :(string, string).</vip>

The second argument no longer refers to the string domain. Instead, you must formulate a new declaration to the predicate, such as

<vip>owns :(name, articles).</vip>

You can describe the articles domain in the domains section as shown here:

<vip>domains
articles = book(string Title, string Author);
horse(string Name).
/* Articles are books or horses */</vip>

The semicolon is read as ''or''. In this case, two alternatives are possible: A book can be identified by its title and author, or a horse can be identified by its name. The domains title, author, and name are all of the standard domain string.

More alternatives can easily be added to the domains declaration. For example, articles could also include a boat, a house, or a bankbook. For a boat, you can make do with a functor that has no arguments attached to it. On the other hand, you might want to give a bank balance as a figure within the bankbook. The domains declaration of articles is therefore extended to:

<vip>domains
articles = book(string Title, string Author);
horse(string Name); boat; bankbook(real Balance).</vip>

Here is a full program that shows how compound domains from the domain articles can be used in facts that define the predicate owns.

<vip>class my
domains
articles =
book(string Title, string Author) ;
horse(string Name) ; boat ; bankbook(real Balance).
predicates
owns :(string Name, articles) nondeterm(i,o) determ(i,i).
end class

implement my
clauses
owns("John", book("A friend of the family", "Irwin Shaw")).
owns("John", horse("Blacky")).
owns("John", boat).
owns("John", bankbook(1000)).
end implement

goal
console::init(),
my::owns("John", Thing),
stdio::write("Thing: ", Thing, "\n"),
fail
;
stdio::write("The end.").</vip>

Now load the program into Visual Development Environment and run it in window. Visual Prolog responds with:

<vip>Thing: book("A friend of the family","Irwin Shaw")
Thing: horse("Blacky")
Thing: boat()
Thing: bankbook(1000)
The end.</vip>

===Writing Domain Declarations: a Summary===

This is a generic representation of how to write compound domain declarations:

<vip>domain = alternative1(D, D, ...);
alternative2(D, D, ...);
...</vip>

Here, alternative1 and alternative2 are arbitrary(but different) functors. The notation(D, D, ...) represents a list of domain names that are either declared elsewhere or are one of the standard domain types(such as string, integer, real, etc).

===='''Note''':====

*The alternatives are separated by semicolons.

*Every alternative consists of a functor and, possibly, a list of domains for the corresponding arguments.

*If the functor has no arguments, you can write it as alternativeN or alternativeN( ) in your programs.

===Multi-Level Compound Domains===

Visual Prolog allows you to construct compound domains on several levels. For example, in

<vip>book("The Ugly Duckling", "Andersen").</vip>

instead of using the author's last name, you could use a new structure that describes the author in more detail, including both the author's first and last names. By calling the functor for the resulting new compound domain author, you can change the description of the book to

<vip>book("The Ugly Duckling", author("Hans Christian", "Andersen")).</vip>

In the old domain declaration

<vip>book(string Title, string Author).</vip>

the second argument of the book functor is Author that can only include a single name, so it is no longer sufficient. You must now specify that an author is also a compound domain made up of the author's first and last name. You do this with the domain definition:

<vip>author = author(string First_name, string Last_name).</vip>

which leads to the following declarations:

<vip>domains
articles = book(string Title, string Author); ...
/* First level */
author = author(string First_name, string Last_name).
/* Second level */</vip>

When using compound domains on different levels in this way, it is often helpful to draw a "tree":

<pre> book
/ \
/ \
title author
/ \
/ \
First_name Last_name</pre>A domain declaration describes only one level of the tree at a time, and not the whole tree. For instance, a book can't be defined with the following domain declaration:

<vip>/* Not allowed */
book = book(string Title, author(string First_name, string Last_name)).</vip>

==Compound Mixed-Domain Declarations==

In this section, we discuss three different types of domain declarations you can add to your programs. These declarations allow you to use predicates that

*take an argument, more than one type of more than one possible type

*take a variable number of arguments, each of a specified type

*take a variable number of arguments, some of which might be of more than one possible type

===Multiple-Type Arguments===

To allow a Visual Prolog predicate to accept an argument that gives information of different types, you must add a functor declaration. In the following example, the your_age clause will accept an argument of type age, which can be a string, a real, or an integer.

<vip>domains
age = i(integer); r(real); s(string).

class predicates
your_age :(age).
clauses
your_age(i(Age)) :- stdio::write(Age).
your_age(r(Age)) :- stdio::write(Age).
your_age(s(Age)) :- stdio::write(Age).</vip>

Visual Prolog does not allow the following domain declaration:

<vip>/* Not permitted. */
domains
age = integer; real; string.</vip>

===Lists===

Suppose you are keeping track of the different classes a professor might teach. You might produce the following code:

<vip>class predicates
teacher :(string First_name, string Last_name, string Class) determ.

clauses
teacher("Ed", "Willis", "english1").
teacher("Ed", "Willis", "math1").
teacher("Ed", "Willis", "history1").
teacher("Mary", "Maker", "history2").
teacher("Mary", "Maker", "math2").
teacher("Chris", "Grahm", "geometry").</vip>

Here, you need to repeat the teacher's name for each class he or she teaches. For each class, you need to add another fact to the database. Although this is perfectly OK in this situation, you might find a school where there are hundreds of classes; this type of data structure would get a little tedious. Here, it would be helpful if you could create an argument to a predicate that could take on one ''or more'' values.

A list in Prolog does just that. In the following code, the argument class is declared to be of a list type. We show here how a list is represented in Prolog.

<vip>domains
classes = string*. /* declare a list domain */

class predicates
teacher :(string First_name, string Last_name, classes Classes) determ.
clauses
teacher("Ed", "Willis", ["english1", "math1", "history1"]).
teacher("Mary", "Maker", ["history2", "math2"]).
teacher("Chris", "Grahm", ["geometry"]).</vip>

In this example, the code is more concise and easier to read than in the preceding one. Notice the domains declaration. The asterisk(*) means that classes is a list of strings. You can just as easily declare a list of integers:

<vip>domains
integer_list = integer*.</vip>

Once you declare a domain, it is easy to use it; just place it as an argument to a predicate declared in the predicates section. Here is an example of using an integer list:

<vip>domains
integer_list = integer*.

class predicates
test_scores :
(string First_name,
string Last_name,
integer_list Test_Scores)
determ.
clauses
test_scores("Lisa", "Lavender", [86, 91, 75]).
test_scores("Libby", "Dazzner", [79, 75]).
test_scores("Jeff", "Zheutlin", []).</vip>

In the case of ''Jeff Zheutlin'', notice that a list doesn't need to contain any elements at all.

One more example shows how one can use lists to describe the family-tree.

<vip>domains
tree_list = tree*.
tree = tree(string Text, tree_list TreeList).

class predicates
family :(tree) determ.
clauses
family(tree("Grandmother",
[tree("John",
[tree("Eric", []),
tree("Mark", []),
tree("Leonard", []) ] ),
tree("Ellen", [])
]
)).</vip>

==Summary==

These are the important points covered in this tutorial:

*A Visual Prolog program can contain many types of values: simple and compound, standard and user-defined.

*Simple values are numbers, strings, etc.

*''Compound domains'' allow you to treat several pieces of information as a single item. A compound domain consists of a name(known as a functor) and one or more arguments. You can define a domain with several alternative functors.

*A functor in Visual Prolog is not the same thing as a function in other programming languages. '''''A functor does not stand for some computation to be performed.''''' It is just a name that identifies a kind of a compound domain and holds its arguments together.

*Compound values can be regarded and treated as single values; you use the functor to distinguish between different kinds of compound values. Visual Prolog allows you to construct compound values on several levels; the arguments of a compound value can also be compound values. With compound mixed domain declarations, you can use predicates that:

*take an argument of more than one possible type(functor declaration).

*take a variable number of arguments, each of a specified type(list declaration).

*take a variable number of arguments, some of which might be of more than one possible type.

==References==

[[Category:Tutorials]]

CGI Applications

2007-10-03T09:40:36Z

Kari Rastas:

{{CGI Applications Navbar}}

'''CGI''' stands for [[wikipedia:Common Gateway Interface|'''C'''ommon '''G'''ateway '''I'''nterface]]. It is a specification recommended by the World Wide Web Consortium for one kind of information streaming in and out of web servers.

As you maybe know, HTML browsers (such as Internet Explorer, Netscape etc.) send and receive information from web servers. But the experience of the world wide web is not a simple act of just reading some hyper-linked HTML files. There is interaction. Data moves both in and out of a browser, including data filled into forms in the browser by the user. There are many things the web server cannot handle on its own. How does it then handle such interactive data?

A web server is a primitive creature actually. It usually serves out HTML files; and other files of mime-types that it recognizes, back to the browsers. It usually cannot do advanced stuff, like accessing a database in the background and sending database queries back to the browsers. CGI was invented to increase the functionality of web servers. It allows web servers to talk to CGI applications residing on the same machine as the web server itself. CGI applications do the job that the web server by itself is unable to do. For example; accessing databases in the background or conducting sophisticated searches. Web servers that use CGI, are usually able to send more information to the browsers than those that do not use CGI.

===What is the significance of a 'common gateway?'===

The word 'common' signifies that the convention is accepted by all web servers. The word 'gateway' represents the fact that data is obtained, as if by stepping through a 'door' or a gateway into other processes that lay on the other side. Metaphorically, a web server stands on one side of the gateway and a CGI application stand on the other side and both of them ''talk'' to each other using CGI.

===What is streaming?===

By the term streaming, we mean that the information is processed one character at a time in a long queue. Think of a pipe whose diameter allows only one character to pass through at any instance. The characters passing through the pipe will emerge at the other pipe end, only one character at a time, in the form of a stream.

Just like in a pipe, where water cannot go streaming in both directions; a stream in the programming world cannot be both readable and writable simultaneously. Either characters come out from the stream (which means the stream is a readable stream), or characters are placed into the stream (a writable stream) but the same stream cannot be used for both purposes by a single program.

In the case of CGI applications, the characters are in '''ANSI''' format, and so they are 8-bit characters. This point has to be noted later on, as Visual Prolog by default uses '''UNICODE''' characters, which are 16-bit. There are predicates available in Visual Prolog that collect streamed ANSI characters together, so processing streams would not be a problem. Eventually, it must be pointed out, our experience of the world wide web happens because of the streaming characters arriving through the Internet pipeline into our browsers one character at a time. We just don't notice it though, because once the individual characters reach the browser, they are quickly assembled together.

===What is a mime-type?===

Think of mime-type as a file extension. It tells the web server the kind of files it and its clients (i.e., browsers) can handle. Most web servers determine the mime-type by the file extensions it sees. When a browser interacts with a web server, it initially informs the web server about the mime-type handling capabilities the browser has, along with the resource (file of a particular mime-type, etc.) it wants the web server to give. The web server sends over the requisite file to the browser for the browser to display. Examples are: .html, .jpg, .gif, etc. Non-recognized mime-types are either not sent to the browser by the web server, or are sent as plain ASCII or as HTML (the actual behavior depends on the web server).

As the information is sent as a stream to the browser, the web server embeds some headers at the start of the stream, containing the mime-type. See Illustration 1 for a typical example of what gets sent across from a web server to a browser. Once these files with mime-types reach the browser, it analyzes the headers, deduces the mime-type the data represents, and as per its own internal table of mime-types it can handle, it displays the data accordingly.

[[Image:cgiApplicationsInVisualProlog06.jpg|frame|Illustration 1]]

===What is a header?===

A header, in the context of this tutorial, is a line of text followed by a carriage return embedded in the stream before the actual data begins. In Illustration 1, the lines you see above the data, are the headers that were passed by the web server to the browser. There is a blank line separating the headers from the actual data.

Notice the 'Content-type:...' header in the illustration. That line indicates the mime-type of the data. This particular line is specifically relevant to CGI applications, as when a web server calls on the services of a CGI application to provide data to be passed on to a browser, it is clueless on the mime-type of the data that the CGI application would be giving. Hence, by convention, the CGI application is responsible for pass this particular header before the rest of the data (separated by a blank line). Note this point carefully when we actually get around to programming CGI applications, because forgetting either the Content-type header or the blank line (between the set of headers and the actual data), or both is a common occurrence and it can lead to a lot of agony.<br />

===What is a CGI application?===

A CGI application or a gateway program (see Illustration 2) is an executable file (usually an .exe file), which does not receive any information via the keyboard or the mouse, i.e., it is not an interactive application (a GUI application would be an interactive application). Such applications are known as console applications. They receive their inputs using the ''stdin'' stream and they put out their outputs into the ''stdout'' stream.<br />
The rest of the headers are added by the web server after a CGI application does its work, and the compiled information is then passed to the browser.

[[Image:cgiApplicationsInVisualProlog07.jpg|frame|Illustration 2]]

In case of CGI applications, once you start them, they terminate on its own without any inputs from you. You can say that they work ''automatically'' like the old DOS command line programs such as xcopy, or format, etc.

A CGI application, however, is not just any console application. It would expect the inputs as per the CGI specification and its outputs should also conform to the CGI specification.

In certain situations, a CGI application can be written as a .DLL file; but such variations are web server dependent. There are even more exotic variations possible. For example, even batch files (.bat files) can be made into simple CGI applications, provided the web server is configured to accept such files as CGI applications. Let us not get into those variations. For the purpose of this tutorial we'll assume that a CGI application is an executable, console application (.exe file), adhering to the CGI specifications.

===What are ''stdin'' and ''stdout'' streams?===

''stdin'' is the name given in various programming languages, to a special stream that acts as the input stream from the underlying OS (Operating System). Programs (such as those written in Visual Prolog) can read the ''stdin'' stream, and use the characters given by that stream as their input. Similarly, ''stdout'' is a stream managed by the OS into which programs will output their characters into.

The ''stdout'' and ''stdin'' streams can be daisy chained (i.e joined end to end) from different programs. For example, a program 'A' can write into its ''stdout'' stream, and then call a program 'B', which in turn will use the ''stdin'' stream to pick up what was written by the program 'A'. This is essentially the transfer mechanism used by web servers: in the previous example, the program 'A' represents the web server and the program 'B' is the CGI application. The ''stdin'' and ''stdout'' streams are often referred together as the console.

===How does the flow of information take place, using CGI?===

The information flow starts from a request placed by the client (i.e., the browser) with the web server. As noted before, the client tells the web server about the various capabilities it has, and also speciies the information that it requires from the web server. See Illustration 3, which shows what gets sent by a browser (the client) to the web server.

[[Image:cgiApplicationsInVisualProlog08.jpg|frame|Illustration 3]]

The first line contains the method field. This indicates the desired HTTP method, the resource being requested, the protocol version, etc., i.e., GET /Tests/file.html HTTP/1.0''.'' Though /Test/file.html looks like a path, it is actually known as a URL (Uniform Resource Locator) and it represents a whole lot of things; including actual filenames and directories on the machine where the web server is located.

Other common methods are '''POST''' (for sending data from the client to the server (not as part of the URL)) and '''HEAD''' (retrieve only header information about the resource).Other fields contain information about the client. The '''Accept:''' fields tell the server the different types of data that the client can accept. These are sent as MIME Content-type messages. Thus Accept: text/plain means that the client can accept plain text files, and so on. This MIME type is important, as this is how web servers tell clients the type of data being sent. The other headers are informational: '''User-Agent:''' - a program making the request, '''From:''' - who is making the request, '''Referer:''' - gives the URL of the document making this request, and so on. The server responds by returning the desired data. It first sends server response headers, which communicate information about the state of the transaction, the type of data being sent, and any additional information. This is followed by a blank line and then the actual data being sent to the client. We saw this, in Illustration 1. Where does the CGI come into this?, - you may wonder. Well, let us re-visit the requested resource, which is in the above example /Tests/file.htm''l,'' if instead of that, it was /cgi-bin/helloworld.exe. Many web servers are configured to let the partial URL /cgi-bin/ indicate that helloword.exe is a CGI program, which the WEB server must invoke.

Hence helloword.exe would be called by the web server and it would pass on some information to helloworld.exe using some environment variables and the ''stdout'' stream (which is the ''stdin'' stream for helloworld.exe). The web server will then wait till the CGI application, helloworld.exe, finishes its work.

Once helloworld.exe ceases execution, the web server would gather the data written by helloworld.exe (including the Content-type header), and send it to the waiting browser.

Phew! All that should ideally happen in the smallest period possible.

Thankfully, all web servers are designed to do its job well and so we do not have to worry about the assembly work performed by a web server after it invokes a CGI application. Let us concentrate instead on how a CGI application should read information from the web server and then pass its data back to the web server, after doing its work.

===What is an environment variable?===

All OS (Operating Systems) allow programmers to insert name=value relationships in what are known as environment variables, somewhere in the computer's RAM (Random Access Memory). For example; the PATH setting in DOS is an environment variable. You can examine the various environment variables that are set for DOS (or Windows XP or Windows 2000 for that matter) using the SET command. Just give SET command on a command line prompt, and the console will display all the currently available environment variables. (In the displayed list, you would see PATH also).

The best part of the concept of environment variables is that you can cook up your very own variables and assign values to them. For example; if you want to keep a password around somewhere, you could do this using the SET command at the OS command line:

<pre>SET password=xyze</pre>Though the value is a string, you don't have to give quotes. All values are internally stored as strings, and they are retrieved by Visual Prolog programs as strings. The significance of environment variables in CGI applications is that a web server uses various environment variables also to pass information to the CGI application that it invokes. Here is an example.

We learnt that a web server places a lot of data on the ''stdout'' stream before calling a CGI application. How does the CGI application know the number of characters to read from the flowing stream? To facilitate this, the web server places the content length into an environment variable called, CONTENT_LENGTH, and using that environment variable's value the CGI application can read the right amount of characters from the stream. Let us examine some Visual Prolog code from cgi.pro (as part of the CGI pack that came with Visual Prolog) that does this:<br />

<vip>clauses
retrieve_POST_string() = Result :- % Get the length
LenStr = environment::getVariable('CONTENT_LENGTH'),
Len = toTerm(LenStr),
%Read the stream to the desired length only
Stream = console::getConsoleInputStream(),
Stream:setMode(stream::ansi(ansi())),
%The stream is in ANSI mode!
Result = Stream:readString(Len).</vip>

Apart from CONTENT_LENGTH, most web servers set the following ''standard'' environment variables before starting a CGI application. A few additions and subtractions may be possible to these environment variables, depending on the web server that you use. The CGI application, in turn can then look for those variables and use the values that are contained therein. The reader is requested to read about these environment variables elsewhere, else this tutorial would become too lengthy. Of these, the environment variable HTTP_REFERER can be useful in implementing some simple security measures (described later in Section B of the tutorial).

<pre>PATH_INFO
PATH_TRANSLATED
REMOTE_HOST
REMOTE_ADDR
GATEWAY_INTERFACE
SCRIPT_NAME
REQUEST_METHOD
HTTP_ACCEPT
HTTP_ACCEPT_CHARSET
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_FROM HTTP_HOST
HTTP_REFERER
HTTP_USER_AGENT
HTTP_COOKIE
QUERY_STRING
SERVER_SOFTWARE
SERVER_NAME
SERVER_PROTOCOL
SERVER_PORT
CONTENT_TYPE
CONTENT_LENGTH
USER_NAME
USER_PASSWORD
AUTH_TYPE</pre>

===How do I test CGI applications?===

You would need to have a web server installed, along with your CGI application in order to test it. You would also need support HTML files, which will trigger the CGI application through the web server. They will obviously vary from one application to another. You'll become aware of such support files, when you study the examples.

As indicated somewhere before, a CGI application has to be placed in the same machine, where the web server is itself running. For reasons of security, a web server is able to fetch files from only a specific set of directories (the set is known as the web-path) on the host machine. Therefore, you should place a CGI application files (CGI executable file and HTML files) into one of these directories.If that was not the case, some malicious user may try to fetch files that should not have been retrievable.

Similarly, a web server can only invoke a CGI application if it is placed in the right directory. You cannot place the CGI application anywhere on the web-path (well, a few web server do allow that too, but not all). Now, all web servers have a configuration method (a separate configuration file, or an .ini file or the windows registry, etc.) to configure its various settings. One of the crucial settings is the location of the CGI applications. When you zero in on a web server for your CGI application, the first thing you should study is how that particular web server configures its CGI application directories.

===Which web server to use?===

As indicated before, web servers are not complicated pieces of software. There are many web servers available free of cost. A large list can be seen at: http://www.serverwatch.com/stypes/index.php/d2Vi . That list includes both commercial software as well as free ones. The complexity of the web server is usually the configuration of the web-path and CGI application directory/directories of the web server.

The TCP-IP protocol should be installed in the computer where the web server is to be setup (It usually would be, if you are able to browse the Internet from that computer) Once you have successfully installed a web server, you should be able to get data from the web server by supplying either the IP address or the domain name of the machine where the web server is installed. Please note that the CGI programs should work fine with the most of web servers including the IIS5 web server which is usually included with Windows 2000 by Microsoft.

===Where to place the CGI application?===

Ensure that the CGI application is placed correctly in such a web server's appropriate script directory. This will vary from a web server to a web server. In this tutorial, we will assume that you have placed it in such a directory that it can be invoked using a browser on the server machine with the following URL: '''<nowiki>http://localhost/cgi-bin/</nowiki>'''''<APPNAME>''.

For example, if you have a CGI application called example1.exe, then it should be accessible with the following URL, on the server machine: '''<nowiki>http://localhost/cgi-bin/example1.exe</nowiki>'''.

===Can you show me a very simple CGI application created using Visual Prolog?===

Yes, indeed! You should unzip the file example1.zip that is included into cgitutorial.zip into a convenient place and examine the Visual Prolog files therein. But, you can create such an application from scratch too by following the instructions given below.

Start a new Visual Prolog project. Note that the UI Strategy is Console:

[[Image:cgiApplicationsInVisualProlog01.png]]

The main Project tree would get displayed. It will include all the necessary files that the VDE has intelligently decided you may require.

[[Image:cgiApplicationsInVisualProlog02.jpg]]

Now, click on the main ''Build'' menu, and in that menu, select ''Build'' or press Alt-F9. You'll notice something magical, as the build process continues. As the project is being built, the VDE will pull in all the relevant PFC (Prolog Foundation Classes) files that were not visible earlier in the Project Tree. After the build process is over, the Project Tree will now look like this:

[[Image:cgiApplicationsInVisualProlog03.jpg]]

Congratulations! You have finished 95% of the job. Now you would be having a console application in the EXE folder of your project, which currently does nothing. We need now to add the relevant code to transform the application into a CGI application

As explained in the earlier sections of this tutorial, a CGI application expects some input from the ''stdin'' stream (Along with some environment variables), then it does its work and sends out the output through the ''stdout'' stream. As this is a very simple CGI application (our very first one) we'll ignore all input arriving into our CGI application from the ''stdin'' stream, (which the web server may be sending to the CGI application). Instead, we'll make our little application send some output.

Double click on the file '''example1.pro''' in the Project Tree, and go towards the end of the code:

[[Image:cgiApplicationsInVisualProlog04.jpg]]

You'll notice that the main goal of the program invokes a predicate called run from the PFC module mainEXE. That module in turns invokes the predicate called run() from example1.pro, so let us have a look at that:

<vip>clauses
run():-
console::init(),
succeed(). % place your own code here</vip>

We'll modify that code to make it look like this:

<vip>clauses
run():-
console::init(), %Line 1
cgi::init(stream::ansi(core::ansi)), %Line 2
stdIO::write("Content-type: text/html\n"), %Line 3
stdIO::write("\n"), %Line 4
stdIO::write("<html><body><h1>Hello World!</h1></body></html>"). %Line 5</vip>

Let us now go through the code, line by line:

*'''Line 1:''' is a Visual Prolog requirement. All work using the ''console'', should first start with console::init() .

*'''Line 2:''' captures the ''stdout'' stream object to CGI output. As explained in the paragraph of this tutorial, the CGI application is expected to send its output to the ''stdout''.

*'''Line 3:''' Now the CGI application is prepared to send the first line back to the calling web server. As explained in the paragraph of this tutorial, the data has to be preceded by some headers. The header which is mandatory is the one that sets the mime-type of the data. Here, it states that the Content-type of the data is of the mime-type text/html. Notice that the line ends in a carriage return (\n).

*'''Line 4:''' To separate the headers from the rest of the data a blank line is needed. It is mandatory as per the CGI specification. So the CGI application now sends a blank line (\n) there. Forgetting to do this is very common in CGI applications (Read the paragraph of this tutorial for more), and it can lead to the malfunctioning of the application.

*'''Line 5:''' In the end the actual data is written out to the ''stdout''. In this example, it is simply creating an HTML file and sending that. The HTML file contains just two words : '''Hello World!'''.

===How to test Example1.exe?===

Place it in the script directory of your web server, as explained earlier. Then access the following URL on the same machine as the web server '''<nowiki>http://localhost/cgi-bin/example1.exe</nowiki>''' using a suitable browser.

===What is the functionality of such a primitive application?===

The ''Hello World'' CGI application (Example1) is not actually as primitive as it seems. It is simple alright, but it can serve as the seed for much sophisticated stuff. Take the last line (Line 6 explained in Paragraph of this tutorial). There the complete HTML is created and then dispatched over the ''stdout'' stream to the web server, who in turn, sends it to the requesting browser. If you introduce a database access at that point, and add some more predicates for conditional processing of the data from the background databases, you can easily build a content management system

===What about inputs?===

As indicated earlier, we have ignored whatever inputs the web server may have given to our little application. If the CGI application needed some inputs, then the ''stdin'' stream would have to be read, and processed for information. Also, the environment variables set at the time of the CGI application operation would also have to be examined. This can be a little complex. Luckily for us, we do not have to do much programming in Visual Prolog when developing CGI applications. For example, to know what data the CGI application receives from the web server, all we have to do is to use the cgi::getString() predicate. (We have to include the cgi.pack from the PFC into our project). And if we need the data in a more convenient form, then we can use the cgi::getParamList() predicate. The individual pieces of data are assembled by cgi::getParamList() into name, value pairs similar to environment variables.

==References==

[[Category:Tutorials]]

DLL Memory Handling

2007-10-03T09:34:31Z

Kari Rastas:

[[Heap]] memory that cross a [[wikipedia::/Dynamic-link_library|DLL]] boundary should be handled with care, because the two sides may treat memory differently. In Visual Prolog a [[Garbage Collection|garbage collector]] handles the heap.

== Vip/Vip ==

When the caller and callee are both in Visual Prolog (and compiled with the same version of Visual Prolog), then memory can simply be passed back and forth as you wish, because both caller and callee will use the same garbage collector for the heap management. So in this case the DLL boundary is completely transparent.

'''Notice''': If caller and callee are compiled with different version of Visual Prolog, then they are '''foreign''' to each other and memory must be handled accordingly.

== Foreign/Vip ==

Visual Prolog's garbage collector does not know whether a foreign program uses a piece of memory or not, and therefore it may reclaim the memory even though the foreign part of the program still needs it (most likely this will result in an access violation at some later point). Therefore you must decide on a memory handling scheme. Basically there are two schemes to choose.

=== Caller provides memory ===

This scheme is used in most Windows API calls and in most C/C++ context. The principle is that the caller allocates the memory and the callee copies the result into that memory.

In you getString case the vip declaration would look like this:
<vip>class dllExport
predicates
getString : (string ResultBuffer) language stdcall.
end class dllExport</vip>

Notice that the string parameter is an input argument. This is because the caller must provide a buffer for the result. (Very often there would also be another argument stating the size of the buffer, such that the DLL will not write outside the buffer).

The corresponding implementation could look like this:
<vip>implement dllExport
clauses
getString(Buffer) :-
Result = "ResultString",
ByteCount = sizeOfDomain(char) * (sting::length(Result)+1),
memory::copy(uncheckedConvert(pointer, Buffer), uncheckedConvert(pointer, Result), ByteCount).
end implement dllExport</vip>

The last two lines in the clause should be turned into a separate predicate (in fact, it should ought to be in PFC already, but I can't seem to find it).

=== Callee provides a clean-up routine ===

An alternative approach is to allow callee memory to float into the caller, and then give the caller a predicate to call once the memory should be released.

In the getString example it could look like this:
<vip>class dllExport
predicates
getString : () -> string ResultBuffer language stdcall.
predicates
releaseString : (string ToRelease) language stdcall.
end class dllExport</vip>

In this case the caller will simply receive the string from the DLL, but once the caller is done with the string it must call releaseString to have it released.

In the implementation we have to make sure that the memory is not garbage collected until releaseString has been called. We can achieve this by asserting the string in a class fact and retract it when it is released, because memory that can be reached from a class fact is never garbage collected.

<vip>implement dllExport
class facts
keepAlive : (pointer ToKeepAlive).
clauses
getString() Result :-
Result = "ResultString",
assert(keepAlive(uncheckedConvert(pointer, Result))).
clauses
releaseString(ToRelease) :-
retractAll(keepAlive(uncheckedConvert(pointer, ToRelease))).
end implement dllExport</vip>

The reason that I assert pointers and not strings, is because otherwise the retract might retract a wrong string, because strings are retracted based on their value (i.e. the characters in the string). Pointers are also retracted based on their value, but their value is a memory address.

Fundamental Visual Prolog - GUI

2007-10-03T09:26:20Z

Kari Rastas:

{{FundamentalVisualPrologNavbar}}

In this tutorial, we shall add a simple [[wikipedia:Graphical_User_Interface|Graphical User Interface]] (GUI) front end to the family project, which was developed in an earlier tutorial. We shall learn to do create and edit most of the GUI components of a simple Windows program directly within the Visual Prolog IDE (Integrated Development Environment). We shall learn a bit about handling of GUI events (like clicking a button on a specific part of the GUI, etc.), and how they work within a Visual Prolog program. We shall also learn about modal dialogs with two examples: one, which is inbuilt by the Windows operating system, and one, which we shall build for ourselves for our program.

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

==Introduction to a GUI==

A GUI is simply an acronym for Graphical User Interface. In the Windows operating system environment the term represents the familiar windows with the menu bar, toolbar, the little buttons on the top right hand corner of a window, etc. Each of those elements is known as a GUI component, and in well designed programs, these components work as per conventionally accepted norms.

In programming terms, a GUI does two things. It uses complex graphical routines to put (and restore) graphical images on the relevant parts of the computer monitor. (E.g. the little square with an X on it on the top right corner of a window). It also controls the behaviour of the mouse and other input devices over these graphical areas. Mercifully, both these detailed programming are done by the operating system. As a programmer one need not get down on our knees to program such graphic, mouse and keyboard functions. Windows does it for us. It has given an API (Application Programming Interface) which can be used to setup the GUI required for any program.

Furthermore, Visual Prolog has added one more layer - the PFC (Prolog Foundation Classes) to help out not only with the GUI but with other areas of programming too.

And even more; the Visual Prolog IDE can be used to visually create the mock-ups of the final GUI that would be used by the program that you would be developing. In this tutorial we shall set out to do just that. We will be using the logic of the family example that was tackled in a previous tutorial.

There is a lot of difference between a GUI and console programs. Though both console programs and GUI programs always starts at a fixed entry point (from the ''Goal'' procedure), that is where the similarity ends. Console programs do not show graphical elements, so they have the user input either from start-up parameters or from direct questions setup by the programmer in advance. The sequence and direction of activities in the program would have to be determined by the programmer. The user cannot modify that sequence. In a console program, the program is started from the ''Goal'' procedure and it is then worked logically from that point onwards, straitjacketing the user through a series of logical steps set out by the programmer.

With GUI programs, the programmer can choose to be flexible. The user can be given options what should be done on which part of the program. For example; if you start any conventional Windows program, it normally will not press you to do this or do that. You can laze around casually flipping through the menus without really clicking on any of them. Consider this scenario: The File menu will have several menu items. You can take the mouse cursor through each one of them without really being compelled to click on any of the menu item you may find there. In fact, one of the common methods by which people get to grips with a piece of software is by such casual browsing over the GUI of a program.

Anyway, to cut a long story short; the programmer has to use a different strategy when programming GUI programs. On one hand, the programming is easier because there is no rigidity or regimentation in the activities of the program that will be carried out.

But on the other hand, the programmer needs to know how each of the GUI components works, what are conventionally accepted practices and how to adhere to those practices so that the user is not given unnecessary surprises when using the program. Also, sometimes it would be difficult to predict the consequences that may follow due to some GUI event being triggered. Hence the programmer has to carefully isolate the logic so that it remains valid irrespective of how the GUI was used, and carefully accommodate those situations, where the program's logic may be unable to accommodate (using polite, easy to understand warning dialogs, etc.).

==GUI: Responding to Events==

In a GUI program, all the GUI components wait for inputs from the keyboard and/or mouse (and/or other pointing devices such as digitizer puck, etc.).

The information from such input devices (click of a mouse and other such GUI activity) is known as an ''event''. There are other ''events'' to which a GUI responds - some of them are internally generated by the operating system such as ticking of the internal clock, interaction with other programs running concurrently, ActiveX events, etc. Depending on what the program is expected to do, the programmer earmarks appropriate portions of code to respond to relevant ''events''. PFC GUI package provides the set of listeners and responders to handle GUI events.

When the program responds to an event, the program can either ''listen'' the event or ''handle'' the event. If an ''event'' is listened, then it means the program can just do something. For example the ''show event'' comes, when a window is shown, hence program can make some initialization here. If an ''event'' is responded, then it means the program can change the behaviour of the system. For example, on the ''close event'' the program can respond either to close window or to keep it open.

Please notice also that the GUI program actually does nothing but waits till a GUI event is invoked.

One important feature of event handling must be understood here:

Because the code of a listener and a responder wait till an event has happened; it may seem as if there is no obvious logic to it. Other modules need not even know what is happening privately within the class which was actually handling a GUI event. In our earlier tutorial, we noticed that all the logic was well contained and logically connected to one another. But in case of GUI programs, parts of the code (the one that handles GUI events) would be ''fragmented'' and placed under different listeners and responders.

In this tutorial, we shall go about taking the same logic of the family example which was dealt in an earlier tutorial, and then use that logic via a GUI interface.

==Starting a GUI Project==

Let us start at the very beginning (a very good place to start!). When we create the project in the Visual Prolog IDE, make sure that the UI strategy is set to '''PFC GUI'''.

The IDE then creates the initial set of modules required to handle the GUI along with the GUI component resources: the main menu, one top toolbar, one bottom status bar, the About dialog and the main Task Window of the program.

Just after you create a project in this fashion, you can immediately compile it to get an empty GUI program. At this stage, the program actually would not do anything. However, it will have all the basic functionality expected in a GUI program. Visual Prolog has simply constructed the essential skeleton of a working GUI program and has provided some features commonly required.

For example; within the main window (known here as the Task Window) of the application Visual Prolog gives another window titled Messages. This window is used internally to act as the ''console''. When the programmer uses the stdio::write(...) predicate in the program, the output would get directed to this Messages window. If Visual Prolog has not redirected the output of PFC class stdio to the Messages window, those strings would not be seen, as a GUI environment does not have a console area by default.

In a console application, the console is always available as a ''blackboard'' onto which the programmer can deposit output. That is why those applications are known as ''console'' applications. We saw that in an earlier tutorial that we could simply write to the ''console'' in such an application using stdio::write(...) predicate.

When you run our compiled GUI program at this stage, you would notice that you can flip through the menus, re-size the outer main window (or Task Window'')'' of the program, double click on the Messages window to zoom it full extents within the Task Window, etc. Visual Prolog even gives a small pop-up menu for the Messages window which is often convenient. Right click anywhere inside the Messages window, and a small menu would open up with which you can clear the contents of the Messages window and do other activities.

But at this point this simple GUI program does not have any logical functionality that we desire. We need to do some further work to achieve this functionality.

Before we embark on populating the project with the actual working logic of the program, we shall create and/or modify some GUI components that we need. Under normal circumstances, it is here where the programmer would have to spend some time thinking out a strategy for the GUI of the program. A clear list of GUI components would have to be made, and only then one should embark on the creation and/or modification of the components. This activity should not be carried out in an unplanned manner. But for the sake of simplicity, we shall proceed in this tutorial with the assumption that this planning process is over.

All GUI components are stored as separate resource files during the coding phase. In most other programming languages; these resource files are separately compiled and then included into the main code during the linking process. Visual Prolog deals with all this resource compilation and linkage issues automatically without unnecessarily bothering the user.

==Creating a Modal Dialog==

Now we shall add another GUI component that we would need later on in our program. It is a dialog box which will be used to feed the name of a person to the program for the program to process. In the Project tree (where all the modules and resources are listed in a clearly laid out tree menu), right click on the Task Window and from the context menu, select New in Existing Package...

[[Image:FundamentalVisualPrologGui02.jpg]]

The Create Project Item dialog would be presented. Ensure that Dialog is selected from the left hand side and on the right hand side enter the AncestorDialog.

A default dialog is created for you to edit. As we will not be implementing a Help function for this dialog, we will click on that particular GUI component (i.e. the Help button) and we shall delete that by pressing the DEL key.

[[Image:FundamentalVisualPrologGui04.jpg]]

Then the other two buttons should be selected and should be shifted about on the dialog box in order to make the dialog look presentable. The final result would look something as shown below:

[[Image:FundamentalVisualPrologGui05.jpg]]

Using the dialog editing controls, we shall now insert a static text. (The word ''static'' implies a non-clickable GUI element). Refer the previous image. On clicking the static text creation button, we can mark out the rectangular area, where our text would appear as seen below:

[[Image:FundamentalVisualPrologGui06.jpg]]

On releasing the mouse you will see the control on the dialog. Left click on the just created control and the properties panel would show the properties of the created control. Under the Text field, write "Person": as seen below. That would be the text which would appear inside the dialog.

[[Image:FundamentalVisualPrologGui07.jpg]]

In a similar fashion, we shall use the dialog editing controls to insert an editable text field or an edit control, as seen below:

[[Image:FundamentalVisualPrologGui08.jpg]]

This time, we shall leave the text field empty and instead change the name to something meaningful (instead of the default name which is given by the IDE) as seen below. This name is used within the program code to refer to this edit field in the program's code as fact variable.

[[Image:FundamentalVisualPrologGui09.jpg]]

This is how finally our dialog would look like:

[[Image:FundamentalVisualPrologGui24.jpg]]

We have one last step which is needed to be performed. Each dialog has a property known as a ''Visit Order''. That is the order by which the controls (i.e. GUI components that interact with the user) on that dialog are visited, when the user clicks on the TAB key. The phrase "''visit a control''" means that the said control receives the ''input focus''. (But then that is more jargon!) The phrase ''the control receiving the input focus'', means the said control which is immediately receptive to inputs from the keyboard. For example; if the edit field had the input focus one would see the blinking caret within the field ready to accept characters entered through the keyboard.

In order to change the visit order, right click on the dialog, and click on Visit Order in the context menu that opens up.

Small buttons will appear on some of the GUI components of the dialog box as shown in the figure below. As seen here, the text edit control (''idc_ancestordialog_personname'') has a visit order of 3 whereas the visit order number for the OK button is 1.

This means that when the dialog is presented to the user, the text edit will not be the one which will receive keyboard characters immediately. When the user presses the TAB button, then the focus will shift to the Cancel button, and only on pressing the TAB button one more time would the focus will go to the edit control. Only then the text edit control would receive keyboard input.

In short, the edit field can be said to have the last ''visit order'' number, with respect to all the controls in the dialog.

[[Image:FundamentalVisualPrologGui25.jpg]]

We need to change this. Click on the small button labeled 3. This will open up the Visit Order dialog box as shown above. You can change the order using the ''+'' and ''-'' buttons. In our case, we will use the change the visit order so that ''idc_ancestordialog_personname'' has a visit order of 1. Now, when the dialog gets used in the program; the input focus will first be on the edit control.

Please note that in dialogs, there is another property called the ''default push button'' which can be set separately from the visit order. An event for the button that has been set to be the ''default push button'' will be triggered on pressing the ENTER key irrespective of which control had the ''input focus''. Usually, the default push button is set to be the OK button.

When you right-click on the dialog, you can set the overall dialog attributes using the following dialog. If you notice, the Type of the dialog is set to Modal. The term ''modal'' reflects the fact that whenever the dialog is presented to the user, the GUI would stop responding to other parts of the program, when the dialog is visible. Only when the dialog is disposed off by the user (by pressing the OK or Cancel button) the GUI will become responsive once again to all GUI activity.

When you click on the dialog, you can set the overall dialog properties on the properties panel. If you notice, the Type of the dialog is set to Modal. The term modal reflects the fact that whenever the dialog is presented to the user, the GUI would stop responding to other parts of the program, when the dialog is visible. Only when the dialog is disposed off by the user (by pressing the OK or Cancel button) the GUI will become responsive once again to all GUI activity.

A ''modeless'' dialog on the other hand does not make this restriction. The entire GUI interface is responsive even if the dialog is active. Programming a ''modeless'' dialog requires a little bit more thought and it is not touched upon in this tutorial.

[[Image:FundamentalVisualPrologGui30.jpg]]

Using the same Dialog Attributes (see figure above), you should also change the title to the "Ancestor of ...".

==Modifying the Menu==

Now we shall modify the main menu of the program. As noted before, the IDE would have provided a default menu consisting of some standard menu items which are found in many programs. We need to edit that menu to suit our program's functionality. Using the project tree, double click on the TaskMenu.mnu item as seen below:

[[Image:FundamentalVisualPrologGui10.jpg]]

This will start the Menu Editor. The main dialog of the Editor is seen below. Click on the Edit button after ensuring that the TaskMenu.mnu is selected in the project window.

This will open up the following Menu Item Attributes dialog, as shown above. We will change the name from ''&Edit'' to ''&Query''. The ampersand sign (&) before Q indicates the letter which would get underlined in the menu. Users can use that alphabet to quickly access the menu.

You can test this feature by clicking on the Test button in the above dialog. The top menu of the IDE will be temporarily replaced by the menu you are designing. You can then browse the menu just to get a feel of it. You can open it submenus, etc. To exit the test mode, you can click somewhere in the IDE window out of the tested menu.

[[Image:FundamentalVisualPrologGui12.jpg]]

We shall now return back to the main TaskMenu dialog. Double click on the ''&Query'' entry, and you would notice that it still contains the menu items of the old Edit menu (Undo, Redo, Cut, Copy and Paste). Delete all the menu items you see within for that main menu entry (&Query). Also change the Constant Prefix setting to ''id_query''. The constant prefix is used internally by the IDE to construct the constants that would represent the various menu items. Those constants would be used internally in the code to refer to the menu items.

Now we shall add some menu items under the main Query menu item. To do that, click on the New '''SubItem''' item and enter the information you see in the following figure:

[[Image:FundamentalVisualPrologGui14.jpg]]

You would note that the Constant is automatically created for you depending on the text you enter for the menu item. In the above example it would be ''id_query_father'' as seen in the previous figure. In a similar fashion, create menu entries for &Grandfather and &Ancestor of ...

Note that by convention an ellipsis (three dots) is used at the end of those menu items which will yield another dialog before any work is carried out. In the above example, &Father and &Grandfather menu items will not have the ellipsis. But the &Ancestor of ... entry will have the ellipsis, because on invoking that menu item, a dialog would open up before any activity gets done.

One last step is remaining in the editing of the TaskWindow menu. By default, when the IDE creates the menu, the File|Open menu is disabled. You would have to locate that menu item, and enable it by removing the checkmark from that menu item's Menu Item Attributes dialog, as seen below:

[[Image:FundamentalVisualPrologGui16.jpg]]

By the way, in the previous figure you would note that you can set the accelerator (i.e. the hot-key) which can be invoked by the user to quickly invoke the same function as the menu item. In the above example, it would be the F8 function key. It should also be noted that the menu item for opening a file is indicated here as &Open (without an ellipsis). You should correct that so that it reads &Open ... to suit the ellipsis convention.

When you close the TaskMenu creation dialog, the IDE would confirm whether you want to save the menu. Click on Save.

[[Image:FundamentalVisualPrologGui15.jpg]]

==Modifying the Toolbar==

The toolbar of the application is another useful GUI component. Usually, it would contain buttons representing some of the functions of various menu items. In short, those buttons act as short cuts to the menu. We shall now go about editing the program's toolbar. A default toolbar is created for the program by the Visual Prolog IDE when you first create the project. From the Project Tree, double-click on the ProjectToolbar.tb.

[[Image:FundamentalVisualPrologGui26.jpg]]

This will invoke the toolbar editor. Note that the top portion represents the toolbar that you are editing and the bottom portion indicates the various controls that are available for you to edit those toolbar components.

In the toolbar, you would notice a set of buttons with predefined iconic images (as commonly accepted in GUI programs) If so desired, you can change those iconic images too but in this tutorial we shall not get into that fine detail. It should be indicated here that the Visual Prolog IDE does contain a nifty little icon editing program right inside it. For larger images, the IDE opens MS Paint for editing.

The buttons have been mapped out to a set of menu-item functions. But as we have now edited the menu items, we shall also edit the toolbar buttons and map it to the correct locations.

Firstly, we need to remove the buttons representing cut, copy and paste as our program does not have those capabilities. Hence select those buttons and delete them from the toolbar. After deletion the toolbar should look as follows:

[[Image:FundamentalVisualPrologGui28.jpg]]

We shall now map the Undo, Redo and the Help buttons to represent the following menu items: Query|Father''..''., Query|Grandfather... and Query|Ancestor of ...

(As noted before, we would not be changing the images of those buttons in this tutorial.)

Double click on the Undo toolbar button and in the Button Attributes dialog that is presented, change the Constant that internally represents the toolbar button from ''id_edit_undo'' to ''id_query_father''.

[[Image:FundamentalVisualPrologGui29.jpg]]

In the same dialog box, you should change the Status Text from:

<vip>Undo;Undo</vip>

to

<vip>Query fathers;List of all fathers listed in the database</vip>

The semicolon in the above string breaks up the string into two parts. The first part is displayed as a tool-tip on the button itself and the second one will appear in the status-line of the main window.

In a similar fashion; change the Redo button's constant so that it is now having the value of ''id_query_grandfather''. And the Help button's constant should get the value of ''id_query_ancestor_of''. The status-line of these two buttons also should be suitably modified.

==Getting the Main Code into the Program==

We have finished all the work for all the GUI functionality that we need from the program. Now we shall start inserting the logic of the code. Before we do that, let us understand some important differences between the way programming used to be done and how it would now be done for a GUI program.

When a user uses a GUI program, it is like the user is using a room. The user comes into the room through the main door all right but once inside the room; the user is free to decide which part of the room would be put to use. Undoubtedly, the programmer has the last say on how each of those parts would actually work. But by and large the user is free to decide which part of the program to activate. The ''Goal'' procedure is still present in a GUI program but here all it does is to just set up the stage for the user to work on. It is like the main door to the room in our analogy.

What does this imply for the programmer? The logic of the code earlier was contained inside one module. Now it will be spread over several modules, depending on the logic which is controlled by corresponding GUI components.

Let us add some basic logical code that is needed by the program. Open TaskWindow.pro and locate the editing caret just after the line:

<vip>classInfo(className, classVersion).</vip>

...once the editing caret is there, then insert the following code into that location:

<vip>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 anyflow.
clauses
grandfather(Person, Grandfather) :-
parent(Person, Parent),
father(Parent, Grandfather).

class predicates
ancestor : (string Person, string Ancestor) nondeterm anyflow.
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).</vip>

The above code is the logical core of the program. In this tutorial, we would directly be inserting it into the module TaskWindow.pro because we want you to see how the GUI components reach into the logical core to perform various actions. In more complex examples; the logical core would be residing separately, sometimes spread over several modules. The GUI modules (such as ''TaskWindow'', etc.) would then be referring it to those modules separately by increasing the ''scope'' of the module (discussed in an earlier tutorial).

Actually, it would be good practice to keep the logical core of the program separate from all GUI related modules as far as possible, but in this tutorial we shall knowingly ignore this sound advice.

==Encapsulating the Interactive Code==

Now that the very core logic has been taken care of, we need to insert the interactive bits. In the Project Tree right click on TaskWindow.win entry. This entry represents the Windows resource for that main TaskWindow. All clicks, menu events, etc. happening within that TaskWindow will have to be handled using event handlers written for that window. On right clicking at that selection, a small context menu would open up as shown below. Select Code Expert from that menu.

[[Image:FundamentalVisualPrologGui17.jpg]]

The Dialog and Window Expert (shown below) helps you set default listeners and responders for controls (interactive GUI components) of a particular window or a dialog. The blue filled circle indicates that there is no listener or responder for the indicated control. The green tick-mark indicates that a listener or responder is present.

[[Image:FundamentalVisualPrologGui18.jpg]]

Using the above dialog, ensure that an event handler is set for the menu item represented by the constant ''id_file_open''.

Now, in the Project tree click on the TaskWindow.pro module so that it becomes selected, and using the Build menu just compile that module. If the TaskWindow.pro module is not selected then the Compile menu item in the ''Build'' menu would be disabled, so beware!

When Visual Prolog compiles a module, it reorganizes the project tree so that all the pertinent predicates/domains, etc. get laid out cleanly for us to access. Hence, we would be using this feature to ensure that the IDE lists out all the predicates that are declared in the TaskWindow.pro module. We can then navigate to the predicate we want.

Note that the IDE intelligently recognizes that TaskWindow.pro may need some additional modules, and it compiles the module in two passes.

After the compilation is over; when we refer to the TaskWindow predicates, in the project tree you would notice that all the predicates are seen:

[[Image:FundamentalVisualPrologGui19.jpg]]

You will find that the Predicates portion of the taskwindow.pro module would reveal the onFileOpen predicate -- which was absent earlier.

When you double-click on that predicate, it will open the editor directly at the location of the clause of the onFileOpen predicate. In case there are multiple clauses, then it would take the cursor to the first clause body.

The onFileOpen predicate is called a ''listener''. As a programmer you need not call this predicate on your own. Windows will automatically call it when the appropriate GUI component is activated (in this case the menu item is clicked)

By default the following code would have been inserted for this event handler:

<vip>onFileOpen(_Source, _MenuTag).</vip>

Replace that code with the following:

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

If you examine the above code, you would notice that we have simply added a clause body above the one given by the IDE. The first clause body will open up the standard Windows dialog box from where the database can be loaded. The second clause body acts as a fail-safe mechanism in case the person cancels that dialog box.

If we now build the program at this stage and run it, you would be able to load a ''family'' database into the program using the File|Open menu item. To test this, you can use the same fa.txt database that was developed for the console version of this program. A message appearing in the Messages window will inform you in case the program was able to load a database successfully.

Note that though the dialog would be asking for ''"''.txt''"'' files, they should not be confused with common text files used in computers. The files that are to be used are to be formatted exactly as per our programs requirements. Any other file would result in an error.

If the file gets loaded correctly, then the stdIO::writef(...) predicate is called to indicate that result. A GUI program does not have a regular console but Visual Prolog GUI programs automatically provide a Messages which acts as a stdout console. Hence the stdIO::writef(...) predicate results gets presented in the Messages. (If you had closed the window, then you would not be able to se the result). You can even re-size or zoom the Messages window, to suit your taste.

Now you should go back to the Dialog and Window Expert, and ensure that the listeners for the Query|Father, Query|Grandfather and Query|Ancestor of ... menu items are also set as shown below:

[[Image:FundamentalVisualPrologGui22.jpg]]

Now for the Query|Father menu item, add the following clause body before the default clause body inserted automatically by Visual Prolog:

<vip>predicates
onQueryFather : window::menuItemListener.
clauses
onQueryFather(_Source, _MenuTag):-
stdIO::write("\nfather test\n"),
father(X, Y),
stdIO::writef("% is the father of %\n", Y, X),
fail.
onQueryFather(_Source, _MenuTag).</vip>

For the Query|Grandfather... menu item, add the following clause body before the default clause body inserted automatically by Visual Prolog:

<vip>predicates
onQueryGrandfather : window::menuItemListener.
clauses
onQueryGrandFather(_Source, _MenuTag) :-
stdIO::write("\ngrandFather test\n"),
grandfather(X, Y),
stdIO::writef("% is the grandfather of %\n", Y, X),
fail.
onQueryGrandFather(_Source, _MenuTag).</vip>

==Understanding What we have Done So Far==

Let us now pause our tutorial and take a breather (phew!). "Where is the encapsulation?", - you should ask. Well, we have broken up the code into two parts. There is the non-interactive logical core which we took care of earlier. But those parts which requires inputs from the user, has been squirrelled away in separate portions into ''different'' event handlers. As far as the rest of the program is concerned, it need not be even aware where those event handlers are actually written in the program. Now, let us insert some more interactive code into yet another event handler.

For the Query|Ancestor of ... menu item, add the following clause body before the default clause body inserted automatically by Visual Prolog:

<vip>predicates
onQueryAncestorOf : window::menuItemListener.
clauses
onQueryAncestorOf(_Source, _MenuTag) :-
X = ancestorDialog::tryGetName(This),
stdIO::writef("\nancestor of % test\n", X),
ancestor(X, Y),
stdIO::writef("% is the ancestor of %\n", Y, X),
fail.
onQueryAncestorOf(_Source, _MenuTag).</vip>

The strategy for the above code is to acquire a string from a modal dialog box presented by the ancestorDialog which we had created earlier. The above predicate assumes that there is a globally accessible predicate called tryGetName available in the ''ancestorDialog'' module which will return the name of the person whose ancestors we are seeking.

As was seen in the onFileOpen Event Handler, we had sought a string (the filename) returned from a modal dialog. The modal dialog itself was invoked by the predicate vpiCommonDialogs::getFileName(...) It is the same strategy that we are adopting for obtaining a string from the ancestorDialog. The only difference is that vpiCommonDialogs::getFileName(...) gave a built-in standard Windows modal file dialog. But for our home grown ancestorDialog, we would have to do some more coding as we shall shortly see.

On compiling the program, there will be one error:

error c229: Undeclared identifier 'ancestorDialog::tryGetName/1->'

The reason for this error is because the onQueryAncestorOf predicate is expecting this globally accessible predicate called tryGetName from the module ancestorDialog.pro. But we haven't written that yet! Let us now get down to rectifying that error.

This predicate is defined within one module, but called from another module. Hence we need to ensure that the declaration is kept not in the .pro l parts of the program. The class declaration file of a module (extension .cl) is one such place. Therefore, let us now open ancestorDialog.cl and insert the following piece of code. (It is a declaration statin called tryGetName is implemented within the module, and that predicate can be called from other modules too.)

<vip>predicates
trygetName : (window Parent) -> string Name determ.</vip>

In ancestorDialog.pro, let us now insert the core logic relevant to that module. Just the way we did for Taskwindow.pro, it is inserted just after the following line:

<vip>classInfo(className, classVersion).</vip>

Here is the code to be inserted:

<vip>domains
optionalString = none(); one(string Value).
class facts
name : optionalString := none().
clauses
tryGetName(Parent) = Name :-
name := none(),
_ = ancestorDialog::display(Parent),
one(Name) = name.</vip>

Now there is one last issue which is remaining. We need to change the event handler for the OK button. This is required, so that the dialog would assert the value entered by the user into the ''name'' class facts. If that is not done, then the above predicate will find an empty string.

The default code given by Visual Prolog is shown below:

<vip>predicates
onOkClick : button::clickResponder.
clauses
onOkClick(_Source) = button::defaultAction.</vip>

The above code now will have to be changed into the following:

<vip>predicates
onOkClick : button::clickResponder.
clauses
onOkClick(_Source) = button::defaultAction :-
Name = idc_ancestordialog_personname:getText(),
name := one(Name).</vip>

Now we have finally finished our program. If you now compile and run the program, you should not get any errors.

==Running the Program==

Once you start the program, you would notice that no activity gets performed immediately, the way it was done in the console program which we had written earlier. As explained somewhere before, starting up a GUI program is like entering a room where the user is free to do things in whichever order he/she chooses. The room simply waits for inputs from the user in whichever order the user decides to give.

Analogously, in our little program, we can invoke the Query|Query Father menu without loading any data. It would not yield any results or any error either because our main logic also takes care of the situation where the data is absent. We can invoke the File|Open... menu item at our choice, and load the family database (the same one which was used in the earlier tutorial).

After that, we can test the Query|Query Father, Query|Query Ancestor and Query|Ancestor of... to see the same results that were obtained in the console program. The results would be displayed in the Messages. (Be careful not to close the Messages window, else the results would not get displayed). The advantage of a GUI program would be recognized when we find that we can run our queries any number of times. Also, we are free to load different data at any point in time.

==Conclusion==

In this tutorial, we have gone through the basics of GUI and how a GUI program can easily be developed in Visual Prolog. We found that the IDE (Integrated Development Environment) given by Visual Prolog allows us complete control over all the GUI components we may wish to use. We were able to edit menus, dialogs and toolbars to suit the functionality that we desire.

Then we were able to modularize the Prolog code and insert it into different parts of the program, so that they are safely encapsulated into different listeners and responders. The non-interactive logical core was kept separately.

A GUI program thus developed can then be used in a very flexible manner, with no compulsion to the user regarding the sequence of activities to be performed with the program.

==References==

[[Category:Tutorials]]

COM Memory Handling in Visual Prolog

2007-10-03T09:17:23Z

Kari Rastas:

The [[wikipedia:Component_object_model|Component Object Model]] (COM) implies usage of COM memory. When we use an external COM component or create our own COM component, we should handle parameters correctly.

The IDE generates necessary memory conversions, allocations and releasing on creating of COM package using component's type library. So normally, you do not have to consider the memory handling. However, sometimes some code is written manually, and then the rules must be known.

The possible situations are:

*Call a COM predicate, which returns a parameter in COM memory;

*Call a COM predicate with input parameter;

*Call a COM predicate with input mutable parameter;

*Implement a COM predicate, which gives us a parameter in COM memory;

*Implement a COM predicate, which returns a parameter in COM memory;

*Implement a COM Predicate. In/Out Parameter;

Please notice that integral parameters do not need special memory handling, but strings and structure domains require such memory handling.

==Call a COM Predicate. Handle Returned Memory==

When we use an external COM component, we can call a predicate, which returns COM memory to us. Usually we want to use the returned information for some time; hence we should copy the returned memory and free the COM memory then. Once the data is copied to Prolog memory it is controlled by the garbage collector.

In the example below, the returned parameter has string type.

<vip>clauses
p() = Parameter:-
HResult = someComPredicate(ComParameter),
HResult = s_ok,
!,
Parameter= string::createCopy(ComParameter),
comMemory::taskMemFree(ComParameter).
p() = "".</vip>

==Call a COM Predicate. Fill Input Parameter==

When we use an external COM component, we can call a predicate, which requires our information. We can use any memory for such input parameters. If we use COM memory, then we should free it after the predicate invocation.

In the example below the parameter has myDom type.

<vip>domains
myDom = myDom(integer X, string S).
clauses
q(myDom(X, S)) :-
HResult = someComPredicate(myDom(X, S)),
check(HResult).</vip>

The IDE uses COM memory for input parameters when generating COM code. The IDE also generates the code to release the COM memory.

==Call a COM Predicate. Fill Mutable Parameter==

When we use an external COM component, we can call a predicate, which requires our information and which changes it. We should use COM memory for such parameters. After the call we should free the result COM memory.

In the example below, the parameter has myDom type.

<vip>domains
myDom = myDom(integer X, string S).
clauses
q(myDom(X, S)) = myDom(NewX, NewS):-
ComParameterPtr= comMemory::taskMemAlloc(sizeofdomain(myDom)),
ComS= comMemory::allocString(S),
memory::copy(ComParameterPtr,
uncheckedConvert(pointer,myDom(X, ComS)),
sizeofdomain(myDom)),
ComParameter= uncheckedConvert(myDom, ComParameterPtr)
HResult = someComPredicate(ComParameter),
ComParameter= myDom(NewX, NewComS),
NewS= string::createCopy(NewComS),
comMemory::taskMemFree(NewComS),
comMemory::taskMemFree(ComParameter),
check(HResult).</vip>

Please notice that inner fields can be changed, so it is necessary to find new values and release them.

==Implement a COM Predicate. Handle Input Memory==

When we create our own COM component or when we implement a callback predicate, we can receive a parameter in COM memory.

It is important to notice that this memory should '''not''' be released.

But if we are going to use the information for some time, then we should copy the memory.

In the example below, the parameter has bstr type.

<vip>clauses
someComPredicate(ComParameter) = s_ok :-
trap(somePredicate(basicString::toString(ComParameter)),
TraceId, processTraceId(TraceId)),
!.
someComPredicate(_) = e_fail.

clauses
somePredicate(Parameter) :-
%some implementation here</vip>

Please also notice that Prolog predicates should be trapped, as the COM system cannot process Prolog fail or Prolog exception.

==Implement a COM Predicate. Return Memory==

When we create our own COM component or when we implement a callback predicate, we can be asked about a parameter. Such a parameter must be allocated in COM memory.

So, we should allocate COM memory and fill it with proper values.

In the example below the parameter has myDom type.

<vip>domains
myDom = myDom(integer X, string S).
clauses
someComPredicate(ComParameter) = s_ok :-
trap(
(
myDom(X, S) = somePredicate(),
ComParameterPtr = comMemory::taskMemAlloc(sizeofdomain(myDom)),
ComS= comMemory::allocString(S),
memory::copy(ComParameterPtr,
uncheckedConvert(pointer,myDom(X, ComS)),
sizeofdomain(myDom)),
ComParameter= uncheckedConvert(myDom, ComParameterPtr)
),
TraceId, processTraceId(TraceId)),
!.
someComPredicate(uncheckedConvert(myDom, null)) = e_fail.

clauses
somePredicate() = Parameter :-
%some implementation here</vip>

You can notice that inner parameters of structure domains should be handled as well.

Please also notice that Prolog predicates should be trapped, as COM system cannot process Prolog fail or Prolog exception.

==Implement a COM Predicate. In/Out Parameter==

When we create our own COM component or when we implement a callback predicate, we can receive a memory, which can be changed (i.e. [in, out]).

Then we should allocate COM memory, fill it with proper values, and release the replaced COM memory.

In the example below the parameter has myDom type.

<vip>domains
myDom = myDom(integer X, string S).
clauses
someComPredicate(ComParameter) = s_ok :-
trap(
(
myDom(X, ComS)= ComParameter
S = string::createCopy(ComS),
myDom(NewX, NewS) = somePredicate(myDom(X, S)),
ComParameterPtr= uncheckedConvert(pointer, ComParameter),
comMemory::taskMemFree(ComS),
NewComS = comMemory::allocString(NewS),
memory::copy(ComParameterPtr,
uncheckedConvert(pointer,myDom(NewX, NewComS)),
sizeofdomain(myDom))
),
TraceId, processTraceId(TraceId)),
!.
someComPredicate(_) = e_fail.

clauses
somePredicate(Parameter) = NewParameter :-
%some implementation here</vip>

Please notice the replaced parameter is released after invocation of the Prolog predicate. Hence, an exception in an implementation of somePredicate will not crash the mutable input parameter.

==References==

[[Category:Tutorials]]

Lists and Recursion

2007-10-02T21:10:03Z

Kari Rastas: /* Parsing by Difference Lists */

List processing – handling sequences of elements – is a powerful technique in Prolog. In this tutorial, we explain what lists are and how to declare them, and then give several examples that show how you might use list processing in your own applications. We also define two well known Prolog predicates – member and append – while looking at list processing from both a recursive and a procedural standpoint.

After that, we introduce findall, a Visual Prolog standard predicate that enables you to find and collect all solutions to a single goal. We round out this tutorial with a discussion of compound lists – combinations of different types of elements – and an example of parsing by difference lists.

==What Is a List?==

In Prolog, ''a list'' is an object that contains an arbitrary number of other objects within it. Lists correspond roughly to arrays in other languages, but, unlike an array, a list does not require you to declare how big it will be before you use it.

A list that contains the numbers 1, 2, and 3 is written as

<vip>[ 1, 2, 3 ]</vip>

The order of the elements in this list matters:

*Number "1" is the first element,

*"2" - the second,

*"3" - the third.

The list [ 1, 2, 3 ] is different from the list [ 1, 3, 2 ].

Each item contained in the list is known as an element. To form a list data structure, you separate the elements of a list with commas and then enclose them in square brackets. Here are some examples:

<vip>["dog", "cat", "canary"]
["valerie ann", "jennifer caitlin", "benjamin thomas"]</vip>

The same element can be present in the list several times, for example:

<vip>[ 1, 2, 1, 3, 1 ]</vip>

===Declaring Lists===

To declare the domain for a list of integers, you use the domains declaration, like this:

<vip>domains
integer_list = integer*.</vip>

The asterisk means "list of"; that is, integer* means "list of integers."

Note that the word ''"list"'' has no special meaning in Visual Prolog. You could equally well have called your list domain ''zanzibar''. It is the asterisk, not the name that signifies a list domain.

The elements in a list can be anything, including other lists. However, all elements in a list must belong to the same domain, and in addition to the declaration of the list domain, there must be a '''domains''' declaration for the elements:

<vip>domains
element_list = elements*.
elements = ....</vip>

Here ''elements'' must be equated to a single domain type (for example, integer, real, or symbol) or to a set of alternatives marked with different functors. Visual Prolog does not allow you to mix standard types in a list. For example, the following declarations would not properly indicate a list made up of integers, reals, and symbols:

<vip>element_list = elements*.
elements =
integer;
real;
symbol.
/* Incorrect */</vip>

The way to declare a list made up of integers, reals, and symbols is to define a single domain comprising all three types, with functors to show which type a particular element belongs to. For example:

<vip>element_list = elements*.
elements =
i(integer);
r(real);
s(symbol).
/* the functors are i, r, and s */</vip>

(For more information about this, refer to "Compound Lists" later in this tutorial.)

====Heads and Tails====

A list is really a recursive compound object. It consists of two parts: the head, of a list, which is the first element, and the tail, which is a list comprising all the subsequent elements.

'''''The tail of a list is always a list; the head of a list is an element.'''''

For example,

<vip>the head of [a, b, c] is a
the tail of [a, b, c] is [b, c]</vip>

What happens when you get down to a one-element list? The answer is that:

<vip>the head of [c] is c
the tail of [c] is []</vip>

'''''If you take the first element from the tail of a list enough times, you will eventually get down to an empty list ('''[ ]''').'''''

'''''The empty list cannot be broken into head and tail.'''''

This means that, conceptually, lists have a tree structure just like other compound objects. The tree structure of [a, b, c, d] is:

<pre> list
/ \
a list
/ \
b list
/ \
c list
/ \
d []</pre>Further, a one-element list such as [a] is not the same as the element that it contains, because [a] is really the compound data structure shown here:

<pre> list
/ \
a []</pre>

==List Processing==

Prolog provides a way to make a head and a tail of a list explicit. Instead of separating elements with commas, you can separate the head and tail with a vertical bar (|). For instance,

[a, b, c] is equivalent to [a|[b, c]]

and, continuing the process,

[a|[b,c]] is equivalent to [a|[b|[c]]]<br />
<br />
which is equivalent to [a|[b|[c|[]]]]

You can even use both kinds of separators in the same list, provided the vertical bar is the last separator. So, if you really want to, you can write [a, b, c, d] as [a, b|[c, d]]. Table 1 gives more examples.''Table 1: Heads and Tails of Lists''

List Head Tail ['a', 'b', 'c'] 'a' ['b', 'c'] [ 'a' ] 'a' [] /* an empty list */ [ ] undefined undefined [[1, 2, 3], [2, 3, 4], []] [1, 2, 3] [[2, 3, 4], []]Table 2 gives several examples of list unification.

''Table 2: Unification of Lists''

List 1 List 2 Variable Binding [X, Y, Z] [egbert, eats, icecream] X=egbert, Y=eats, Z=icecream] [7] [X | Y] X=7, Y=[] [1, 2, 3, 4] [X, Y | Z] X=1, Y=2, Z=[3,4] [1, 2] [3 | X] fail

==Using Lists==

Because a list is really a recursive compound data structure, you need recursive algorithms to process it. The most basic way to process a list is to work through it, doing something to each element until you reach the end.

An algorithm of this kind usually needs two clauses. One of them says what to do with an ordinary list (one that can be divided into a head and a tail). The other says what to do with an empty list.

===Writing Lists===

For example, if you just want to print out the elements of the list, here is what you do:

<vip>class my
predicates
write_a_list : (integer*).
end class

implement my
clauses
write_a_list([]).
/* If the list is empty, do nothing more. */
write_a_list([H|T]):-
/* Match the head to H and the tail to T, then... */
stdio::write(H),stdio::nl,
write_a_list(T).
end implement

goal
console::init(),
my::write_a_list([1, 2, 3]).</vip>

Here are the two write_a_list clauses described in natural language:

*To write an empty list, do nothing.

*Otherwise, to write a list, write its head (which is a single element), then write its tail (a list).

The first time through, the goal is:

<vip>my::write_a_list([1, 2, 3]).</vip>

This matches the second clause, with H=1 and T=[2, 3]; this writes 1 and then calls write_a_list recursively with the tail of the list:

<vip>my::write_a_list([2, 3]).
/* This is write_a_list(T). */</vip>

This recursive call matches the second clause, this time with H=2 and T=[3], so it writes 2 and again calls write_a_list recursively:

<vip>my::write_a_list([3]).</vip>

Now, which clause will this goal match? Recall that, even though the list [3] has only one element; it does have a head and tail; the head is 3 and the tail is []. So, again the goal matches the second clause, with H=3 and T=[]. Hence, 3 is written and write_a_list is called recursively like this:

<vip>my::write_a_list([]).</vip>

Now you see why this program needs the first clause. The second clause will not match this goal because [] cannot be divided into head and tail. So, if the first clause were not there, the goal would fail. As it is, the first clause matches and the goal succeeds without doing anything further.

===Counting List Elements===

Now consider how you might find out how many elements are in a list. What is the length of a list, anyway? Here is a simple logical definition:

The length of [] is 0.<br />
The length of any other list is 1 plus the length of its tail.

Can you implement this? In Prolog it is very easy. It takes just two clauses:

<vip>class my
predicates
length_of : (A*, integer) procedure(i,o).
end class

implement my
clauses
length_of([], 0).
length_of([_|T], L):-
length_of(T, TailLength),
L = TailLength + 1.
end implement

goal
console::init(),
my::length_of([1, 2, 3], L),
stdio::write(L).</vip>

Take a look at the second clause first. Crucially, [_|T] will match any nonempty list, binding T to the tail of the list. The value of the head is unimportant; as long as it exists, it can be counted it as one element.

So the goal:

<vip>my::length_of([1, 2, 3], L)</vip>

will match the second clause, with T=[2, 3]. The next step is to compute the length of T. When this is done (never mind how), TailLength will get the value 2, and the computer can then add 1 to it and bind L to 3.So how is the middle step executed? That step was to find the length of [2, 3] by satisfying the goal

<vip>my::length_of([2, 3], TailLength)</vip>

In other words, length_of calls itself recursively. This goal matches the second clause, binding

*[3] in the goal to T in the clause and

*TailLength in the goal to L in the clause.

Recall that TailLength in the goal will not interfere with TailLengt''h'' in the clause, because '''''each recursive invocation of a clause has its own set of variables'''''.

So now the problem is to find the length of [3], which will be 1, and then add 1 to that to get the length of [2, 3], which will be 2. So far, so good.

Likewise, length_of will call itself recursively again to get the length of [3]. The tail of [3] is [], so T is bound to [], and the problem is to get the length of [], then add 1 to it, giving the length of [3].

This time it's easy. The goal:

<vip>my::length_of([], TailLength)</vip>

matches the ''first'' clause, binding TailLength to 0. So now the computer can add 1 to that, giving the length of [3], and return to the calling clause. This, in turn, will add 1 again, giving the length of [2, 3], and return to the clause that called it; this original clause will add 1 again, giving the length of [1, 2, 3].

Confused yet? We hope not. In the following brief illustration we'll summarize the calls. We've used subscripts to indicate that similarly named variables in different clauses – or different invocations of the same clause – are distinct. Please notice that you do not need to implement such predicate in your own code, you can use '''list::length''' predicate from PFC.

<vip>my::length_of([1, 2, 3], L1).
my::length_of([2, 3], L2).
my::length_of([3], L3).
my::length_of([], 0).
L3 = 0+1 = 1.
L2 = L3+1 = 2.
L1 = L2+1 = 3.</vip>

===Tail Recursion===

You probably noticed that length_of is not, and can't be, tail-recursive, because the recursive call is not the last step in its clause. Can you create a tail-recursive list-length predicate? Yes, but it will take some effort.

The problem with length_of is that you can't compute the length of a list until you've already computed the length of the tail. It turns out there's a way around this. You'll need a list-length predicate with three arguments.

*One is the list, which the computer will whittle away on each call until it eventually becomes empty, just as before.

*Another is a free argument that will ultimately contain the result (the length).

*The third is a counter that starts out as 0 and increments on each call.

When the list is finally empty, you'll unify the counter with the (up to then) unbound result.

<vip>class my
predicates
length_of : (A*, integer, integer)
procedure(i,o,i).
end class

implement my
clauses
length_of([], Result, Result).
length_of([_|T], Result, Counter):-
NewCounter = Counter + 1,
length_of(T, Result, NewCounter).
end implement

goal
console::init(),
my::length_of([1, 2, 3], L, 0), /* start with Counter = 0 */
stdio::write(" L = ", L).</vip>

This version of the length_of predicate is more complicated, and in many ways less logical, than the previous one. We've presented it merely to show you that, by devious means, '''''you can often find a tail-recursive algorithm for a problem that seems to demand a different type of recursion'''''.

====Another Example – Modifying the List====

Sometimes you want to take a list and create another list from it. You do this by working through the list element by element, replacing each element with a computed value. For example, here is a program that takes a list of numbers and adds 1 to each of them:

<vip>class my
predicates
add1 : (integer*, integer*) procedure(i,o).
end class

implement my
clauses
add1([], []).
/* boundary condition */
add1([Head|Tail],[Head1|Tail1]):-
/* separate the head */
/* from the rest of the list */
Head1 = Head+1,
/* add 1 to the first element */
add1(Tail, Tail1).
/* call element with the rest of the list */
end implement

goal
console::init(),
my::add1([1,2,3,4], NewList),
stdio::write(NewList)).</vip>

To paraphrase this in natural language:

To add 1 to all the elements of the empty list,<br />
just produce another empty list.<br />
<br />
To add 1 to all the elements of any other list,<br />
add 1 to the head and make it the head of the result, and then<br />
add 1 to each element of the tail and make that the tail of the result.

Load the program, and run the goal with the specified goal

<vip>add1([1,2,3,4], NewList).</vip>

The goal will return

<code language="text">NewList=[2,3,4,5]
1 Solution</code>

<h6>Tail Recursion Again</h6>

Is add1 tail-recursive? If you're accustomed to using Lisp or Pascal, you might think it isn't, because you think of it as performing the following operations:

*Split the list into ''Head'' and ''Tail''.

*Add 1 to ''Head'', giving ''Head1''.

*Recursively add 1 to all the elements of ''Tail'', giving ''Tail1''.

*Combine ''Head1'' and ''Tail1'', giving the resulting list.

This isn't tail-recursive, because the recursive call is not the last step.

But – and this is important – '''''that is not how Prolog does it'''''. In Visual Prolog, add1 is tail-recursive, because its steps are really the following:

*Bind the head and tail of the original list to ''Head'' and ''Tail''.

*Bind the head and tail of the result to ''Head1'' and ''Tail1''. (''Head1'' and ''Tail1'' do not have values yet.)

*Add 1 to ''Head'', giving ''Head1''.

*Recursively add 1 to all the elements of ''Tail'', giving ''Tail1''.

When this is done, ''Head1'' and ''Tail1'' are ''already'' the head and tail of the result; there is no separate operation of combining them. So the recursive call really is the last step.

<h6>More on Modifying Lists</h6>

Of course, you don't actually need to put in a replacement for every element. Here's a program that scans a list of numbers and copies it, leaving out the negative numbers:

<vip>class my
predicates
discard_negatives : (integer*, integer*) procedure(i,o).
end class

implement my
clauses
discard_negatives([], []).
discard_negatives([H|T], ProcessedTail):-
H < 0,
!, /* If H is negative, just skip it */
discard_negatives(T, ProcessedTail).
discard_negatives([H|T], [H|ProcessedTail]):-
discard_negatives(T, ProcessedTail).
end implement

goal
console::init(),
my::discard_negatives ([2, -45, 3, 468], X),
stdio::write(X).</vip>

For example, the goal

<vip>my::discard_negatives([2, -45, 3, 468], X)</vip>

gives

<vip>X=[2, 3, 468].</vip>

And here's a predicate that copies the elements of a list, making each element occur twice:

<vip>doubletalk([], []).
doubletalk([H|T], [H, H|DoubledTail]) :-
doubletalk(T, DoubledTail).</vip>

===List Membership===

Suppose you have a list with the names ''John'', ''Leonard'', ''Eric'', and ''Frank'' and would like to use Visual Prolog to investigate if a given name is in this list. In other words, you must express the relation "membership" between two arguments: a name and a list of names. This corresponds to the predicate

<vip>isMember : (name, name*).
/* "name" is a member of "name*" */</vip>

In the e01.pro program, the first clause investigates the head of the list. If the head of the list is equal to the name you're searching for, then you can conclude that Name is a member of the list. Since the tail of the list is of no interest, it is indicated by the anonymous variable. Thanks to this first clause, the goal

<vip>my::isMember("john", ["john", "leonard", "eric", "frank"])</vip>

is satisfied.

<vip>/* Program e01.pro */
class my
predicates
isMember : (A, A*) determ.
end class

implement my
clauses
isMember(Name, [Name|_]) :-
!.
isMember(Name, [_|Tail]):-
isMember(Name,Tail).
end implement

goal
console::init(),
my::isMember("john", ["john", "leonard", "eric", "frank"]),
!,
stdio::write("Success")
;
stdio::write("No solution").</vip>

If the head of the list is not equal to Name, you need to investigate whether Name can be found in the tail of the list.

In English:

Name is a member of the list if Name is the first element of the list, or<br />
Name is a member of the list if Name is a member of the tail.

The second clause of isMember relates to this relationship. In Visual Prolog:

<vip>isMember(Name, [_|Tail]) :-
isMember(Name, Tail).</vip>

===Appending One List to Another: Declarative and Procedural Programming===

As given, the member predicate of the e01.pro program works in two ways. Consider its clauses once again:

<vip>member(Name, [Name|_]).
member(Name, [_|Tail]) :-
member(Name, Tail).</vip>

You can look at these clauses from two different points of view: declarative and procedural.

*From a declarative viewpoint, the clauses say:Name is a member of a list if the head is equal to Name;<br />
if not, Name is a member of the list if it is a member of the tail.

*From a procedural viewpoint, the two clauses could be interpreted as saying:To find a member of a list, find its head;<br />
otherwise, find a member of its tail.

These two points of view correspond to the goals

<vip>member(2, [1, 2, 3, 4]).</vip>

and

<vip>member(X, [1, 2, 3, 4]).</vip>

In effect, the first goal asks Visual Prolog to check whether something is true; the second asks Visual Prolog to find all members of the list [1,2,3,4]. Don't be confused by this. The member predicate is the same in both cases, but its behavior may be viewed from different angles.

====Recursion from a Procedural Viewpoint====

The beauty of Prolog is that, often, when you construct the clauses for a predicate from one point of view, they'll work from the other. To see this duality, in this next example you'll construct a predicate to append one list to another. You'll define the predicate append with three arguments:

<vip>append(List1, List2, List3).</vip>

This combines List1 and List2 to form List3. Once again you are using recursion (this time from a procedural point of view).

If List1 is empty, the result of appending '' Lis''t''1'' and List2 will be the same as List2. In Prolog:

<vip>append([], List2, List2).</vip>

If List1 is not empty, you can combine List1 and List2 to form ''List3'' by making the head of List1 the head of List3. (In the following code, the variable H is used as the head of both List1 and List3.) The tail of List3 is L3, which is composed of the rest of List1 (namely, L1) and all of List2. In Prolog:

<vip>append([H|L1], List2, [H|L3]) :-
append(L1, List2, L3).</vip>

The append predicate operates as follows: While List1 is not empty, the recursive rule transfers one element at a time to List3. When List1 is empty, the first clause ensures that List2 hooks onto the back of List3.

====One Predicate Can Have Different Uses====

Looking at append from a declarative point of view, you have defined a relation between three lists. This relation also holds if List1 and List3 are known but List2 isn't. However, it also holds true if only List3 is known. For example, to find which two lists could be appended to form a known list, you could use a goal of the form

<vip>append(L1, L2, [1, 2, 4]).</vip>

With this goal, Visual Prolog will find these solutions:

<vip>1L1=[], L2=[1,2,4]
L1=[1], L2=[2,4]L1=[1,2], L2=[4]L1=[1,2,4], L2=[]4 Solutions</vip>

You can also use append to find which list you could append to [3,4] to form the list [1,2,3,4]. Try giving the goal

<vip>append(L1, [3,4], [1,2,3,4]).</vip>

Visual Prolog finds the solution

<vip>L1=[1,2].</vip>

This append predicate has defined a relation between an '' input set'' and an ''output set'' in such a way that the relation applies both ways. Given that relation, you can ask

Which output corresponds to this given input?

or

Which input corresponds to this given output?

The status of the arguments to a given predicate when you call that predicate is referred to as a ''flow pattern''. An argument that is bound or instantiated at the time of the call is an input argument, signified by (i); a free argument is an output argument, signified by (o).

The append predicate has the ability to handle any flow pattern you provide. However, not all predicates have the capability of being called with different flow patterns. When a Prolog clause is able to handle multiple flow patterns, it is known as an invertible clause. Many of list predicate can be found in the '''list''' class.

==Finding All the Solutions at Once==

Backtracking and recursion are two ways to perform repetitive processes. Recursion won out because, unlike backtracking, it can pass information (through arguments) from one recursive call to the next. Because of this, a recursive procedure can keep track of partial results or counters as it goes along.

But there's one thing backtracking can do that recursion can't do – namely, find all the alternative solutions to a goal. So you may find yourself in a quandary: You need all the solutions to a goal, but you need them all at once, as part of a single compound data structure. What do you do?

Fortunately, Visual Prolog provides a way out of this impasse. The built-in construction list comprehension takes a goal as one of its arguments and collects all of the solutions to that goal into an output single list. list comprehension takes two arguments:

*The first argument, VarName, specifies which argument in the specified predicate is to be collected into a list.

*The second, mypredicate, indicates the predicate from which the values will be collected.

*The output ListParam, is a variable that holds the list of values collected through backtracking.

The e02.pro program uses list comprehension to print the average age of a group of people.

<vip> /* Program e02.pro */
class my
domains
name = string.
address = string.
age = integer.

predicates
person : (name, address, age)
nondeterm anyflow.
sumlist : (age*, age, integer)
procedure(i,o,o).
end class

implement my
clauses
sumlist([],0,0).
sumlist([H|T], Sum, N):-
sumlist(T, S1, N1),
Sum=H+S1, N=1+N1.
person("Sherlock Holmes",
"22B Baker Street", 42).
person("Pete Spiers",
"Apt. 22, 21st Street", 36).
person("Mary Darrow",
"Suite 2, Omega Home", 51).
end implement

goal
console::init(),
L = [ Age || my::person(_, _, Age)],
my::sumlist(L, Sum, N),
Ave = Sum/N,
stdio::write("Average=", Ave, ". ").</vip>

The list comprehension clause in this program creates a list L, which is a collection of all the ages obtained from the predicate person. If you wanted to collect a list of all the people who are 42 years old, you could give the following subgoal:

<vip>List = [ Who || my::person(Who, _, 42) ]</vip>

The following code will create the list of positive items:

<vip>List = [ X || X = list::getMember_nd([2,-8,-3,6]), X > 0]</vip>

==Compound Lists==

A list of integers can be simply declared as

<vip>integer*</vip>

The same is true for a list of real numbers, a list of symbols, or a list of strings.

However, it is often valuable to store a combination of different types of elements within a list, such as:

<vip>[2, 3, 5.12, ["food", "goo"], "new"].
/* Not correct Visual Prolog*/</vip>

''Compound lists'' are lists that contain more than one type of element. You need special declarations to handle lists of multiple-type elements, because Visual Prolog requires that all elements in a list belong to the '''''same''''' domain. The way to create a list in Prolog that stores these different types of elements is to use functors, because a domain can contain '''''more than one''''' data type as arguments to functors.

The following is an example of a domain declaration for a list that can contain an integer, a character, a string, or a list of any of these:

<vip>domains
/* the functors are l, i, c, and s */
llist = l(list); i(integer); c(char); s(string).</vip>

The list

<vip>[ 2, 9, ["food", "goo"], "new" ]
/* Not correct Visual Prolog */</vip>

would be written in Visual Prolog as:

<vip>[i(2), i(9), l([s("food"), s("goo")]), s("new")]
/* Correct Visual Prolog */</vip>

The following example of append shows how to use this domain declaration in a typical list-manipulation program.

<vip>class my
domains
llist = l(list); i(integer); c(char); s(string).

predicates
append : (A*,A*,A*) procedure (i,i,o).
end class

implement my
clauses
append([], L, L).
append([X|L1], L2, [X|L3]):-
append(L1, L2, L3).
end implement

goal
console::init(),
my::append([my::s("likes"),
my::l([my::s("bill"), my::s("mary")])],
[my::s("bill"), my::s("sue")], Ans),
stdio::write("FIRST LIST: ", Ans,"\n\n"),
my::append([my::l([my::s("This"),
my::s("is"),my::s("a"),my::s("list")]),
my::s("bee")], [my::c('c')], Ans2),
stdio::write("SECOND LIST: ", Ans2, "\n\n&quot).</vip>

===Parsing by Difference Lists===

The ch07e10.pro program demonstrates [[wikipedia:parsing|parsing]] by ''difference lists''. The process of parsing by difference lists works by reducing the problem; in this example we transform a string of input into a Prolog structure that can be used or evaluated later.

The parser in this example is for a very primitive computer language. Although this example is very advanced for this point in the tutorial, we decided to put it here because parsing is one of the areas where Visual Prolog is very powerful. If you do not feel ready for this topic, you can skip this example and continue reading the tutorial without any loss of continuity.

<vip>#include @"pfc\exception\exception.ph"
#include @"pfc\string\string.ph"
#include @"pfc\console\console.ph"

class my_t
predicates
tokl : (string, string*) procedure (i,o).
end class

implement my_t
clauses
tokl(Str, [H|T]) :-
string::fronttoken(Str, H, Str1), !,
tokl(Str1, T).
tokl(_, []).
end implement

/* * * * * * * * * * * * * * * * * *
* This second part of the program
* is the parser *
* * * * * * * * * * * * * * * * * */
class my_p
domains
program = program(statement_list).
statement_list = statement*.
/* * * * * * * * * * * * * * * *
* Definition of what constitutes
* a statement *
* * * * * * * * * * * * * * * */
statement =
if_Then_Else(exp, statement, statement);
if_Then(exp, statement);
while(exp, statement);
assign(id, exp).
/* * * * * * * * * * * * * *
* Definition of expression *
* * * * * * * * * * * * * */
exp = plus(exp, exp);
minus(exp, exp);
var(id);
int(integer).
id = string.

predicates
s_program : (string*, program) procedure (i,o).
s_statement : (string*, string*, statement) determ (i,o,o).
s_statement_list : (string*, string*, statement_list) determ (i,o,o).
s_exp : (string*, string*, exp) determ (i,o,o).
s_exp1 : (string*, string*, exp, exp) determ (i,o,i,o).
s_exp2 : (string*, string*, exp) determ (i,o,o).
end class

implement my_p
clauses
s_program(List1, program(StatementList)):-
s_statement_list(List1, _, StatementList),
!.
s_program(_, program([])).

clauses
s_statement_list([], [], []) :- !.
s_statement_list(
List1, List4, [Statement|Program]) :-
s_statement(List1, List2, Statement),
List2=[";"|List3],
s_statement_list(List3, List4, Program).
s_statement(["if"|List1], List7,
if_then_else(Exp,
Statement1, Statement2)):-
s_exp(List1, List2, Exp),
List2=["then"|List3],
s_statement(List3, List4, Statement1),
List4=["else"|List5],!,
s_statement(List5, List6, Statement2),
List6=["fi"|List7].
s_statement(["if"|List1], List5,
if_then(Exp, Statement)) :- !,
s_exp(List1, List2, Exp),
List2=["then"|List3],
s_statement(List3, List4, Statement),
List4=["fi"|List5].
s_statement(["do"|List1], List4,
while(Exp, Statement)) :- !,
s_statement(List1, List2, Statement),
List2=["while"|List3],
s_exp(List3, List4, Exp).
s_statement([ID|List1], List3,
assign(Id,Exp)) :-
string::isname(ID),
List1=["="|List2],
s_exp(List2, List3, Exp).
s_exp(List1, List3, Exp):-
s_exp2(List1, List2, Exp1),
s_exp1(List2, List3, Exp1, Exp).
s_exp1(["+"|List1], List3, Exp1, Exp) :- !,
s_exp2(List1, List2, Exp2),
s_exp1(List2, List3, plus(Exp1, Exp2), Exp).
s_exp1(["-"|List1], List3, Exp1, Exp) :- !,
s_exp2(List1, List2, Exp2),
s_exp1(List2, List3, minus(Exp1, Exp2), Exp).
s_exp1(List, List, Exp, Exp).
s_exp2([Int|Rest], Rest, int(I)) :-
trap(I = toTerm(Int),Error,
exception::clear_fail(Error)),
!.
s_exp2([Id|Rest], Rest, var(Id)) :-
string::isname(Id).
end implement

goal
console::init(),
my_t::tokl("b=2; if b then a=1 else a=2 fi; do a=a-1 while a;", Ans),
stdio::write(Ans),
my_p::s_program(Ans, Res),
stdio::write(Res).</vip>

Load and run this program, then enter the following goal:

<vip>goal
my_t::tokl("b=2; if b then a=1 else a=2 fi; do a=a-1 while a;", Ans),
my_p::s_program(Ans, Res).</vip>

Visual Prolog will return the program structure:

<vip>Ans = ["b","=","2",";","if","b","then","a","=","1",
"else","a","=","2","fi",";","do","a","=","a",
"-","1","while","a",";"],
Res=program([assign("b",int(2)),
if_then_else(var("b"),assign("a",int(1)), assign("a",int(2))),
while(var("a"),assign("a",minus(var("a"),int(1))))
])
1 Solution</vip>

The transformation in this example is divided into two stages: scanning and parsing. The tokl predicate is the scanner; it accepts a string and converts it into a list of tokens. All the predicates with names beginning in s_ are parser predicates. In this example the input text is a Pascal-like program made up of Pascal-like statements. This programming language only understands certain statements: IF THEN ELSE, IF THEN, DO WHILE, and ASSIGNMENT. Statements are made up of expressions and other statements. Expressions are addition, subtraction, variables, and integers.

Here's how this example works:

*The first scanner clause, s_program, takes a list of tokens and tests if it can be transformed into a list of statements.

*The predicate s_statement_list takes this same list of tokens and tests if the tokens can be divided up into individual statements, each ending with a semicolon.

*The predicate s_statement tests if the first tokens of the token list make up a legal statement. If so, the statement is returned in a structure and the remaining tokens are returned back to s_statement_list.

*The four clauses of the s_statement correspond to the four types of statements the parser understands. If the first s_statement clause is unable to transform the list of tokens into an IF THEN ELSE statement, the clause fails and backtracks to the next s_statement clause, which tries to transform the list of tokens into an IF THEN statement. If that clause fails, the next one tries to transform the list of tokens into a DO WHILE statement.

*If the first three s_statement clauses fail, the last clause for that predicate tests if the statement does assignment. This clause tests for assignment by testing if the first term is a symbol, the second term is "=", and the next terms make up a simple math expression.

*The s_exp, s_exp1, and s_exp2 predicates work the same way, by testing if the first terms are expressions and – if so – returning the remainder of the terms and an expression structure back to s_statement.

==Summary==

These are the important points covered in this tutorial:

*''Lists'' can contain an arbitrary number of elements; you declare them by adding an asterisk at the end of a previously defined domain.

*A list is a recursive compound object that consists of a head and a tail. The head is the first element and the tail is the rest of the list (without the first element). The tail of a list is always a list; the head of a list is an element. A list can contain zero or more elements; the empty list is written [].

*The elements in a list can be anything, including other lists; all elements in a list must belong to the same domain. The domain declaration for the elements must be of this form:

<vip>domains
element_list = elements*.
elements = ....</vip>

where elements = one of the standard domains (integer, real, etc.) or a set of alternatives marked with different functors (int(integer); rl(real); smb(symbol); etc.). You can only mix types in a list in Visual Prolog by enclosing them in compound objects/functors.

*You can use separators (commas, [, and |) to make the head and tail of a list explicit; for example, the list

<vip>[a, b, c, d]</vip>

can be written as:

<vip>[a|[b, c, d]] or[a, b|[c, d]] or[a, b, c|[d]] or[a|[b|[c, d]]] or[a|[b|[c|[d]]]] or even[a|[b|[c|[d|[]]]]]</vip>

*List processing consists of recursively removing the head of the list (and usually doing something with it) until the list is an empty list.

*The list predicates can be found in the '''list''' class.

*Visual Prolog provides a built-in construction, list comprehension, which takes a goal as one of its arguments and collects all of the solutions to that goal into a single list. It has the syntax

<vip>Result = [ Argument || myPredicate(Argument) ]</vip>

*Because Visual Prolog requires that all elements in a list belong to the same domain, you use functors to create a list that stores different types of elements.

*The process of ''parsing by difference lists'' works by reducing the problem; the example in this tutorial transforms a string of input into a Prolog structure that can be used or evaluated later.

==References==

[[Category:Tutorials]]

Introduction to Classes and Objects

2007-10-02T20:47:20Z

Kari Rastas: /* Object Model */

The purpose of the tutorial is to introduce you to the notions of object orientation as met in Visual Prolog, and to give you a quick exemplified introduction to the syntax.

==Object Model==

The main semantic entities in the Visual Prolog [[wikipedia:Object_model|object model]] are [[wikipedia:Object_%28computer_science%29|objects]], object types and classes. The main syntactic notions to deal with these entities are interfaces, class declarations and implementations.

An [[wikipedia:Interface_%28computer_science%29|interface]] is a named set of predicate declarations. Interfaces describe the "interface" of objects (hence the name), i.e. the access that you have to an object from outside the object. Interfaces represent '''''object types'''''.

Consider this interface definition:

<vip>interface person
predicates
getName : () -> string Name.
setName : (string Name).
end interface person</vip>

This is the definition of an interface named person. All objects of the person type have two predicates getName and setName, with declarations as stated above.

Interfaces only define types of objects; it is classes that create the objects. A class has a ''declaration'' and an ''implementation''. A class that ''constructs'' person objects, might be declared like this:

<vip>class person : person
constructors
new : (string Name).
end class person</vip>

This is the declaration of a class named person, which constructs objects of the person type. The class has a ''constructor'' named new, which given a Name will construct an object (i.e. of the person type).

The class will also need an implementation, which might look like this:

<vip>implement person
facts
name : string.

clauses
new(Name) :- name := Name.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

This is the implementation of the class named person. The implementation must provide a definition for each of the public predicates and constructors, i.e. for new, getName and setName. The implementation can also locally declare and define extra entities, which are only accessible in the implementation itself. In this case, the class declares a ''fact variable'' named name, which is used to store the name of the person.

Each object has its own instance of the fact variable name. And the code of the clauses above will all reference that particular instance of the fact variable. We say that the predicates are '''''object''''' '''''predicates''''' and that the fact is an ''''' object fact'''''.

=='''Class Entities'''==

A class can also have entities that are shared among all objects of the class. Let us for example extend the example above with code that counts the number of person objects that are created. This count will increase every time an object is created and never decrease.

I will extend the declaration of the class with a predicate (i.e. getCreatedCount) that can return the current count:

<vip>class person : person
constructors
new : (string Name).

predicates
getCreatedCount : () -> unsigned Count.
end class person</vip>

Notice that publicly accessible '''''class predicates''''' are declared in the class declaration, whereas publicly accessible '''''object predicates''''' are declared in interfaces. This is a rule without exceptions: it is not possible to declare object predicates in a class declaration, and it is not possible to declare class predicates in an interface.

The predicate will need a definition in the implementation of the class; I will also need a fact for storing the count. This fact must be a ''''' class fact''''' (i.e. shared among all the objects). In the ''' implementation''' of a class you can declare and define private object entities as well as private class entities. To declare class entities, you prefix the corresponding declaration section with the keyword class. All in all our class person can be implemented like this:

<vip>implement person
class facts
createdCount : unsigned := 0.

clauses
getCreatedCount() = createdCount.

facts
name : string.

clauses
new(Name) :-
name := Name,
createdCount := createdCount+1.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

I.e. I have added a class fact createdCount, which is initialized to zero. I have also added a clause for the predicate getCreatedCount, which returns the current value of createdCount. Finally, I have added the code in the constructor, which increments the createdCount.

Notice that in the constructor, two assignments have the same shape, but one updates the object state, whereas the other updates the class state.

==Modules==

A special variant of classes does not produce objects at all, and therefore they act as "modules" rather than classes. A non-object constructing class (or simply a module) is declared by omitting the object type in the declaration:

<vip>class io % no type here
predicates
write : (string ToWrite).
write : (unsigned ToWrite).
end class io</vip>

Such a class that does not produce objects (obviously) cannot contain object entities, neither can it have constructors.

==Creation and Access==

Given the code above I can create a ''goal'' that creates an object and uses the io-class (whose implementation I shall not consider here) to write the name of the person.

<vip>goal
P = person::new("John"),
Name = P:getName(),
io::write(Name).</vip>

In the first line I call the '''''constructor''''' new in the class person. The created object is bound to the variable P. In the next line I bind the variable Name to the result of invoking the ''''' object''''' predicate getName on P. In the last line I call the ''''' class''''' predicate write in the class io.

Notice that names in classes are referenced using two colons, e.g. person::new. Also notice that object predicates are referenced using one colon, e.g. P:getName.

Finally, you should notice that constructors are functions that return an object, even though they are not declared like functions: The return type is subsumed from the class declaration.

==Interfaces are Object Types==

As mentioned above interfaces are object types. This should be taken literally, you can use interfaces in the same places where you can use non-object types. For example, in predicate declarations:

<vip>class mail
predicates
sendMessage : (person Recipient, string Message).
end class mail</vip>

The predicate mail::sendMessage takes a person and a string as arguments.

==Multiple Implementations==

You can create several completely different classes that all create person objects. You simply declare and implement more classes that construct person objects. The implementation of the classes can be very different, for example I can create a class that stores the person in a database. This is the declaration of such a class:

<vip>class personInDB : person
constructors
new : (string DatabaseName, string Name).
end class personInDB</vip>

This tutorial is not concerned with actual implementations of this and that. But I hope the code below shows that objects of a certain object type, can have completely different implementation.

<vip>implement personInDB
facts
db : myDatabase.
personID : unsigned.

clauses
new(DatabaseName, Name) :-
db := myDatabase::getDB(DatabaseName),
personID := db:storePerson(Name).

clauses
getName() = db:getPersonName(personID).

clauses
setName(Name) :- db:setPersonName(personID, Name).
end implement personInDB</vip>

You will notice that not only the internal behavior is completely different, but the internal state also has a completely different structure and contents.

==Subsumption Polymorphism==

Objects of the same type can be used in the same context, no matter how different their implementations are. I can, for example, send a message to a person using the mail class declared above, no matter if that person is constructed by person or personInDB:

<vip>goal
P1 = person::new("John"),
mail::sendMessage(P1, "Hi John, ..."),
P2 = personInDB::new("Paul"),
mail::sendMessage(P2, "Hi Paul, ...").</vip>

This behavior is known as subsumption: Objects constructed by one class, are as good as objects constructed by another class in a certain context, as long as both objects have the type required by that context.

You will notice that the predicate mail::sendMessage can equally well take objects from any person class, so this predicate is polymorphic in a certain sense (Subsumption Polymorphism).

==Supports (Type Extension)==

Let us imagine that my program also deals with a special kind of persons, namely the users of the program. Users are persons with a name, but there is more to them, they also have a password. I want to create a new object type/interface for users, which states that a user is a person, with a password. For this I use the supports qualification:

<vip>interface user supports person
predicates
trySetPassword : (string Old, string New, string Confirm) determ.
validatePassword : (string Password) determ.
end interface user</vip>

It is stated that user supports person. This has two effects:

*It means that user objects will have to provide the predicates declared in the person interface (i.e. getName and setName).

*It also means that an object of type user is also an object of type person, and can therefore also be used in contexts that expect a person object.I.e. if we assume that I have a user class:

<vip>class user : user
constructors
new : (string Name, string Password).
end class user</vip>

Then objects of that class can be used by mail::sendMessage:

<vip>goal
P = user::new("Benny", "MyCatBobby"),
mail::sendMessage(P, "Hi Benny, ...").</vip>

An interface can support several other interfaces, meaning that:

*the objects of that type must provide all the predicates in the supported interfaces

*the objects of that type have all the other types as wellAn interface can also support one or more interfaces, which themselves support one or more interfaces, and so forth. And also in that case:

*the objects of that type must provide all the predicates in the indirectly as well as directly supported interfaces

*the objects of that type have all the other indirect as well as direct typesThe supports qualifications generate a subtype hierarchy: we say that user is a subtype of person.

==Object: the Ultimate Object Super-Type==

An interface that does not explicitly support any interfaces, implicitly supports the interface object. object is an implicitly defined interface that has no contents (i.e. no predicates). Any object supports the object interface directly or indirectly, so any object has type object. And therefore object is the super type of all object types.

==Inheritance==

When I want to implement the class user, I will, of course, like to take an advantage of one of our person classes. Let us assume that the user class should resemble the class person, except of course that it also deals with the password. I would like our class user to '''''inherit''''' the implementation of the person part from class person. This is achieved by the following code:

<vip>implement user
inherits
person

facts
password : string.

clauses
new(Name, Password) :-
person::new(Name),
password := Password.

clauses
trySetPassword(Old, New, Confirm) :-
validatePassword(Old),
New = Confirm,
password := New.

clauses
validatePassword(Password) :-
password = Password.
end implement user</vip>

This implementation states that it '''''inherits''''' person, which has the following effects:

*A person object is embedded into each constructed user object.

*All predicates from the person interface can be inherited directly from class person to class user.When you inherit a predicate you do not directly state the implementation of it, instead the implementation from the class that you inherit from is used.

The inheritance can to a certain extend be explained as syntactic sugaring. At least I could have achieved exactly the same effect with the following code (the clauses for the password predicates remains as above):

<vip>implement user
facts
person : person.
password : string.

clauses
new(Name, Password) :-
person := person_class::new(Name),
password := Password.

clauses
getName() = person:getName().

clauses
setName(Name) :- person:setName(Name).

...
end implement user_class</vip>

In this code I do not inherit from class person, instead I create a person object and store it in a fact variable. And instead of inheriting the code for getName and setName I have made trivial implementations of these predicates, which simply delegate the task to the object in the fact variable. A section with the keyword delegate can be used as shortcut for such delegation

This code has very much the same effect, but there are some notable differences:

*First of all I have written more code.

*The person object is not embedded in the user object, instead there is a reference to it. (Also here there are two memory allocations instead of one).

*In the last situation I can ''dynamically'' change the value in the fact variable to another object; simply by assigning a new object to the fact variable. For example, to an object of class personInDB.You should also notice that the second implementation have an extra level of indirection in the call. Visual Prolog handles such indirections rather efficient, but it handles the inheritance even more efficient.

Visual Prolog has multiple inheritance, meaning that you can inherit from many classes simultaneously.

==Final Remarks==

Above I have introduced you to the most fundamental concepts of the object system in Visual Prolog. There are other interesting features in the object system, but these will not be covered here, for example:

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

*Object predicate values, a seamless counterpart to C# delegates.

==References==
[[ru:Введение в Классы и Объекты]]
[[Category:Tutorials]]

Introduction to Classes and Objects

2007-09-22T08:59:17Z

Kari Rastas:

The purpose of the tutorial is to introduce you to the notions of object orientation as met in Visual Prolog, and to give you a quick exemplified introduction to the syntax.

==Object Model==

The main semantic entities in the Visual Prolog [http://en.wikipedia.org/wiki/Object_model object model] are [http://en.wikipedia.org/wiki/Object_%28computer_science%29 objects], object types and classes. The main syntactic notions to deal with these entities are interfaces, class declarations and implementations.

An [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interface] is a named set of predicate declarations. Interfaces describe the "interface" of objects (hence the name), i.e. the access that you have to an object from outside the object. Interfaces represent '''''object types'''''.

Consider this interface definition:

<vip>interface person
predicates
getName : () -> string Name.
setName : (string Name).
end interface person</vip>

This is the definition of an interface named person. All objects of the person type have two predicates getName and setName, with declarations as stated above.

Interfaces only define types of objects; it is classes that create the objects. A class has a ''declaration'' and an ''implementation''. A class that ''constructs'' person objects, might be declared like this:

<vip>class person : person
constructors
new : (string Name).
end class person</vip>

This is the declaration of a class named person, which constructs objects of the person type. The class has a ''constructor'' named new, which given a Name will construct an object (i.e. of the person type).

The class will also need an implementation, which might look like this:

<vip>implement person
facts
name : string.

clauses
new(Name) :- name := Name.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

This is the implementation of the class named person. The implementation must provide a definition for each of the public predicates and constructors, i.e. for new, getName and setName. The implementation can also locally declare and define extra entities, which are only accessible in the implementation itself. In this case, the class declares a ''fact variable'' named name, which is used to store the name of the person.

Each object has its own instance of the fact variable name. And the code of the clauses above will all reference that particular instance of the fact variable. We say that the predicates are '''''object''''' '''''predicates''''' and that the fact is an ''''' object fact'''''.

=='''Class Entities'''==

A class can also have entities that are shared among all objects of the class. Let us for example extend the example above with code that counts the number of person objects that are created. This count will increase every time an object is created and never decrease.

I will extend the declaration of the class with a predicate (i.e. getCreatedCount) that can return the current count:

<vip>class person : person
constructors
new : (string Name).

predicates
getCreatedCount : () -> unsigned Count.
end class person</vip>

Notice that publicly accessible '''''class predicates''''' are declared in the class declaration, whereas publicly accessible '''''object predicates''''' are declared in interfaces. This is a rule without exceptions: it is not possible to declare object predicates in a class declaration, and it is not possible to declare class predicates in an interface.

The predicate will need a definition in the implementation of the class; I will also need a fact for storing the count. This fact must be a ''''' class fact''''' (i.e. shared among all the objects). In the ''' implementation''' of a class you can declare and define private object entities as well as private class entities. To declare class entities, you prefix the corresponding declaration section with the keyword class. All in all our class person can be implemented like this:

<vip>implement person
class facts
createdCount : unsigned := 0.

clauses
getCreatedCount() = createdCount.

facts
name : string.

clauses
new(Name) :-
name := Name,
createdCount := createdCount+1.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

I.e. I have added a class fact createdCount, which is initialized to zero. I have also added a clause for the predicate getCreatedCount, which returns the current value of createdCount. Finally, I have added the code in the constructor, which increments the createdCount.

Notice that in the constructor, two assignments have the same shape, but one updates the object state, whereas the other updates the class state.

==Modules==

A special variant of classes does not produce objects at all, and therefore they act as "modules" rather than classes. A non-object constructing class (or simply a module) is declared by omitting the object type in the declaration:

<vip>class io % no type here
predicates
write : (string ToWrite).
write : (unsigned ToWrite).
end class io</vip>

Such a class that does not produce objects (obviously) cannot contain object entities, neither can it have constructors.

==Creation and Access==

Given the code above I can create a ''goal'' that creates an object and uses the io-class (whose implementation I shall not consider here) to write the name of the person.

<vip>goal
P = person::new("John"),
Name = P:getName(),
io::write(Name).</vip>

In the first line I call the '''''constructor''''' new in the class person. The created object is bound to the variable P. In the next line I bind the variable Name to the result of invoking the ''''' object''''' predicate getName on P. In the last line I call the ''''' class''''' predicate write in the class io.

Notice that names in classes are referenced using two colons, e.g. person::new. Also notice that object predicates are referenced using one colon, e.g. P:getName.

Finally, you should notice that constructors are functions that return an object, even though they are not declared like functions: The return type is subsumed from the class declaration.

==Interfaces are Object Types==

As mentioned above interfaces are object types. This should be taken literally, you can use interfaces in the same places where you can use non-object types. For example, in predicate declarations:

<vip>class mail
predicates
sendMessage : (person Recipient, string Message).
end class mail</vip>

The predicate mail::sendMessage takes a person and a string as arguments.

==Multiple Implementations==

You can create several completely different classes that all create person objects. You simply declare and implement more classes that construct person objects. The implementation of the classes can be very different, for example I can create a class that stores the person in a database. This is the declaration of such a class:

<vip>class personInDB : person
constructors
new : (string DatabaseName, string Name).
end class personInDB</vip>

This tutorial is not concerned with actual implementations of this and that. But I hope the code below shows that objects of a certain object type, can have completely different implementation.

<vip>implement personInDB
facts
db : myDatabase.
personID : unsigned.

clauses
new(DatabaseName, Name) :-
db := myDatabase::getDB(DatabaseName),
personID := db:storePerson(Name).

clauses
getName() = db:getPersonName(personID).

clauses
setName(Name) :- db:setPersonName(personID, Name).
end implement personInDB</vip>

You will notice that not only the internal behavior is completely different, but the internal state also has a completely different structure and contents.

==Subsumption Polymorphism==

Objects of the same type can be used in the same context, no matter how different their implementations are. I can, for example, send a message to a person using the mail class declared above, no matter if that person is constructed by person or personInDB:

<vip>goal
P1 = person::new("John"),
mail::sendMessage(P1, "Hi John, ..."),
P2 = personInDB::new("Paul"),
mail::sendMessage(P2, "Hi Paul, ...").</vip>

This behavior is known as subsumption: Objects constructed by one class, are as good as objects constructed by another class in a certain context, as long as both objects have the type required by that context.

You will notice that the predicate mail::sendMessage can equally well take objects from any person class, so this predicate is polymorphic in a certain sense (Subsumption Polymorphism).

==Supports (Type Extension)==

Let us imagine that my program also deals with a special kind of persons, namely the users of the program. Users are persons with a name, but there is more to them, they also have a password. I want to create a new object type/interface for users, which states that a user is a person, with a password. For this I use the supports qualification:

<vip>interface user supports person
predicates
trySetPassword : (string Old, string New, string Confirm) determ.
validatePassword : (string Password) determ.
end interface user</vip>

It is stated that user supports person. This has two effects:

*It means that user objects will have to provide the predicates declared in the person interface (i.e. getName and setName).

*It also means that an object of type user is also an object of type person, and can therefore also be used in contexts that expect a person object.I.e. if we assume that I have a user class:

<vip>class user : user
constructors
new : (string Name, string Password).
end class user</vip>

Then objects of that class can be used by mail::sendMessage:

<vip>goal
P = user::new("Benny", "MyCatBobby"),
mail::sendMessage(P, "Hi Benny, ...").</vip>

An interface can support several other interfaces, meaning that:

*the objects of that type must provide all the predicates in the supported interfaces

*the objects of that type have all the other types as wellAn interface can also support one or more interfaces, which themselves support one or more interfaces, and so forth. And also in that case:

*the objects of that type must provide all the predicates in the indirectly as well as directly supported interfaces

*the objects of that type have all the other indirect as well as direct typesThe supports qualifications generate a subtype hierarchy: we say that user is a subtype of person.

==Object: the Ultimate Object Super-Type==

An interface that does not explicitly support any interfaces, implicitly supports the interface object. object is an implicitly defined interface that has no contents (i.e. no predicates). Any object supports the object interface directly or indirectly, so any object has type object. And therefore object is the super type of all object types.

==Inheritance==

When I want to implement the class user, I will, of course, like to take an advantage of one of our person classes. Let us assume that the user class should resemble the class person, except of course that it also deals with the password. I would like our class user to '''''inherit''''' the implementation of the person part from class person. This is achieved by the following code:

<vip>implement user
inherits
person

facts
password : string.

clauses
new(Name, Password) :-
person::new(Name),
password := Password.

clauses
trySetPassword(Old, New, Confirm) :-
validatePassword(Old),
New = Confirm,
password := New.

clauses
validatePassword(Password) :-
password = Password.
end implement user</vip>

This implementation states that it '''''inherits''''' person, which has the following effects:

*A person object is embedded into each constructed user object.

*All predicates from the person interface can be inherited directly from class person to class user.When you inherit a predicate you do not directly state the implementation of it, instead the implementation from the class that you inherit from is used.

The inheritance can to a certain extend be explained as syntactic sugaring. At least I could have achieved exactly the same effect with the following code (the clauses for the password predicates remains as above):

<vip>implement user
facts
person : person.
password : string.

clauses
new(Name, Password) :-
person := person_class::new(Name),
password := Password.

clauses
getName() = person:getName().

clauses
setName(Name) :- person:setName(Name).

...
end implement user_class</vip>

In this code I do not inherit from class person, instead I create a person object and store it in a fact variable. And instead of inheriting the code for getName and setName I have made trivial implementations of these predicates, which simply delegate the task to the object in the fact variable. A section with the keyword delegate can be used as shortcut for such delegation

This code has very much the same effect, but there are some notable differences:

*First of all I have written more code.

*The person object is not embedded in the user object, instead there is a reference to it. (Also here there are two memory allocations instead of one).

*In the last situation I can ''dynamically'' change the value in the fact variable to another object; simply by assigning a new object to the fact variable. For example, to an object of class personInDB.You should also notice that the second implementation have an extra level of indirection in the call. Visual Prolog handles such indirections rather efficient, but it handles the inheritance even more efficient.

Visual Prolog has multiple inheritance, meaning that you can inherit from many classes simultaneously.

==Final Remarks==

Above I have introduced you to the most fundamental concepts of the object system in Visual Prolog. There are other interesting features in the object system, but these will not be covered here, for example:

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

*Object predicate values, a seamless counterpart to C# delegates.

==References==
[[ru:Введение в Классы и Объекты]]
[[Category:Tutorials]]

Introduction to Classes and Objects

2007-09-22T08:56:50Z

Kari Rastas: Added a couple of external links

The purpose of the tutorial is to introduce you to the notions of object orientation as met in Visual Prolog, and to give you a quick exemplified introduction to the syntax.

==Object Model==

The main semantic entities in the Visual Prolog [http://en.wikipedia.org/wiki/Object_model object model] are [objects http://en.wikipedia.org/wiki/Object_%28computer_science%29], object types and classes. The main syntactic notions to deal with these entities are interfaces, class declarations and implementations.

An interface is a named set of predicate declarations. Interfaces describe the "interface" of objects (hence the name), i.e. the access that you have to an object from outside the object. Interfaces represent '''''object types'''''.

Consider this interface definition:

<vip>interface person
predicates
getName : () -> string Name.
setName : (string Name).
end interface person</vip>

This is the definition of an interface named person. All objects of the person type have two predicates getName and setName, with declarations as stated above.

Interfaces only define types of objects; it is classes that create the objects. A class has a ''declaration'' and an ''implementation''. A class that ''constructs'' person objects, might be declared like this:

<vip>class person : person
constructors
new : (string Name).
end class person</vip>

This is the declaration of a class named person, which constructs objects of the person type. The class has a ''constructor'' named new, which given a Name will construct an object (i.e. of the person type).

The class will also need an implementation, which might look like this:

<vip>implement person
facts
name : string.

clauses
new(Name) :- name := Name.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

This is the implementation of the class named person. The implementation must provide a definition for each of the public predicates and constructors, i.e. for new, getName and setName. The implementation can also locally declare and define extra entities, which are only accessible in the implementation itself. In this case, the class declares a ''fact variable'' named name, which is used to store the name of the person.

Each object has its own instance of the fact variable name. And the code of the clauses above will all reference that particular instance of the fact variable. We say that the predicates are '''''object''''' '''''predicates''''' and that the fact is an ''''' object fact'''''.

=='''Class Entities'''==

A class can also have entities that are shared among all objects of the class. Let us for example extend the example above with code that counts the number of person objects that are created. This count will increase every time an object is created and never decrease.

I will extend the declaration of the class with a predicate (i.e. getCreatedCount) that can return the current count:

<vip>class person : person
constructors
new : (string Name).

predicates
getCreatedCount : () -> unsigned Count.
end class person</vip>

Notice that publicly accessible '''''class predicates''''' are declared in the class declaration, whereas publicly accessible '''''object predicates''''' are declared in interfaces. This is a rule without exceptions: it is not possible to declare object predicates in a class declaration, and it is not possible to declare class predicates in an interface.

The predicate will need a definition in the implementation of the class; I will also need a fact for storing the count. This fact must be a ''''' class fact''''' (i.e. shared among all the objects). In the ''' implementation''' of a class you can declare and define private object entities as well as private class entities. To declare class entities, you prefix the corresponding declaration section with the keyword class. All in all our class person can be implemented like this:

<vip>implement person
class facts
createdCount : unsigned := 0.

clauses
getCreatedCount() = createdCount.

facts
name : string.

clauses
new(Name) :-
name := Name,
createdCount := createdCount+1.

clauses
getName() = name.

clauses
setName(Name) :- name := Name.
end implement person</vip>

I.e. I have added a class fact createdCount, which is initialized to zero. I have also added a clause for the predicate getCreatedCount, which returns the current value of createdCount. Finally, I have added the code in the constructor, which increments the createdCount.

Notice that in the constructor, two assignments have the same shape, but one updates the object state, whereas the other updates the class state.

==Modules==

A special variant of classes does not produce objects at all, and therefore they act as "modules" rather than classes. A non-object constructing class (or simply a module) is declared by omitting the object type in the declaration:

<vip>class io % no type here
predicates
write : (string ToWrite).
write : (unsigned ToWrite).
end class io</vip>

Such a class that does not produce objects (obviously) cannot contain object entities, neither can it have constructors.

==Creation and Access==

Given the code above I can create a ''goal'' that creates an object and uses the io-class (whose implementation I shall not consider here) to write the name of the person.

<vip>goal
P = person::new("John"),
Name = P:getName(),
io::write(Name).</vip>

In the first line I call the '''''constructor''''' new in the class person. The created object is bound to the variable P. In the next line I bind the variable Name to the result of invoking the ''''' object''''' predicate getName on P. In the last line I call the ''''' class''''' predicate write in the class io.

Notice that names in classes are referenced using two colons, e.g. person::new. Also notice that object predicates are referenced using one colon, e.g. P:getName.

Finally, you should notice that constructors are functions that return an object, even though they are not declared like functions: The return type is subsumed from the class declaration.

==Interfaces are Object Types==

As mentioned above interfaces are object types. This should be taken literally, you can use interfaces in the same places where you can use non-object types. For example, in predicate declarations:

<vip>class mail
predicates
sendMessage : (person Recipient, string Message).
end class mail</vip>

The predicate mail::sendMessage takes a person and a string as arguments.

==Multiple Implementations==

You can create several completely different classes that all create person objects. You simply declare and implement more classes that construct person objects. The implementation of the classes can be very different, for example I can create a class that stores the person in a database. This is the declaration of such a class:

<vip>class personInDB : person
constructors
new : (string DatabaseName, string Name).
end class personInDB</vip>

This tutorial is not concerned with actual implementations of this and that. But I hope the code below shows that objects of a certain object type, can have completely different implementation.

<vip>implement personInDB
facts
db : myDatabase.
personID : unsigned.

clauses
new(DatabaseName, Name) :-
db := myDatabase::getDB(DatabaseName),
personID := db:storePerson(Name).

clauses
getName() = db:getPersonName(personID).

clauses
setName(Name) :- db:setPersonName(personID, Name).
end implement personInDB</vip>

You will notice that not only the internal behavior is completely different, but the internal state also has a completely different structure and contents.

==Subsumption Polymorphism==

Objects of the same type can be used in the same context, no matter how different their implementations are. I can, for example, send a message to a person using the mail class declared above, no matter if that person is constructed by person or personInDB:

<vip>goal
P1 = person::new("John"),
mail::sendMessage(P1, "Hi John, ..."),
P2 = personInDB::new("Paul"),
mail::sendMessage(P2, "Hi Paul, ...").</vip>

This behavior is known as subsumption: Objects constructed by one class, are as good as objects constructed by another class in a certain context, as long as both objects have the type required by that context.

You will notice that the predicate mail::sendMessage can equally well take objects from any person class, so this predicate is polymorphic in a certain sense (Subsumption Polymorphism).

==Supports (Type Extension)==

Let us imagine that my program also deals with a special kind of persons, namely the users of the program. Users are persons with a name, but there is more to them, they also have a password. I want to create a new object type/interface for users, which states that a user is a person, with a password. For this I use the supports qualification:

<vip>interface user supports person
predicates
trySetPassword : (string Old, string New, string Confirm) determ.
validatePassword : (string Password) determ.
end interface user</vip>

It is stated that user supports person. This has two effects:

*It means that user objects will have to provide the predicates declared in the person interface (i.e. getName and setName).

*It also means that an object of type user is also an object of type person, and can therefore also be used in contexts that expect a person object.I.e. if we assume that I have a user class:

<vip>class user : user
constructors
new : (string Name, string Password).
end class user</vip>

Then objects of that class can be used by mail::sendMessage:

<vip>goal
P = user::new("Benny", "MyCatBobby"),
mail::sendMessage(P, "Hi Benny, ...").</vip>

An interface can support several other interfaces, meaning that:

*the objects of that type must provide all the predicates in the supported interfaces

*the objects of that type have all the other types as wellAn interface can also support one or more interfaces, which themselves support one or more interfaces, and so forth. And also in that case:

*the objects of that type must provide all the predicates in the indirectly as well as directly supported interfaces

*the objects of that type have all the other indirect as well as direct typesThe supports qualifications generate a subtype hierarchy: we say that user is a subtype of person.

==Object: the Ultimate Object Super-Type==

An interface that does not explicitly support any interfaces, implicitly supports the interface object. object is an implicitly defined interface that has no contents (i.e. no predicates). Any object supports the object interface directly or indirectly, so any object has type object. And therefore object is the super type of all object types.

==Inheritance==

When I want to implement the class user, I will, of course, like to take an advantage of one of our person classes. Let us assume that the user class should resemble the class person, except of course that it also deals with the password. I would like our class user to '''''inherit''''' the implementation of the person part from class person. This is achieved by the following code:

<vip>implement user
inherits
person

facts
password : string.

clauses
new(Name, Password) :-
person::new(Name),
password := Password.

clauses
trySetPassword(Old, New, Confirm) :-
validatePassword(Old),
New = Confirm,
password := New.

clauses
validatePassword(Password) :-
password = Password.
end implement user</vip>

This implementation states that it '''''inherits''''' person, which has the following effects:

*A person object is embedded into each constructed user object.

*All predicates from the person interface can be inherited directly from class person to class user.When you inherit a predicate you do not directly state the implementation of it, instead the implementation from the class that you inherit from is used.

The inheritance can to a certain extend be explained as syntactic sugaring. At least I could have achieved exactly the same effect with the following code (the clauses for the password predicates remains as above):

<vip>implement user
facts
person : person.
password : string.

clauses
new(Name, Password) :-
person := person_class::new(Name),
password := Password.

clauses
getName() = person:getName().

clauses
setName(Name) :- person:setName(Name).

...
end implement user_class</vip>

In this code I do not inherit from class person, instead I create a person object and store it in a fact variable. And instead of inheriting the code for getName and setName I have made trivial implementations of these predicates, which simply delegate the task to the object in the fact variable. A section with the keyword delegate can be used as shortcut for such delegation

This code has very much the same effect, but there are some notable differences:

*First of all I have written more code.

*The person object is not embedded in the user object, instead there is a reference to it. (Also here there are two memory allocations instead of one).

*In the last situation I can ''dynamically'' change the value in the fact variable to another object; simply by assigning a new object to the fact variable. For example, to an object of class personInDB.You should also notice that the second implementation have an extra level of indirection in the call. Visual Prolog handles such indirections rather efficient, but it handles the inheritance even more efficient.

Visual Prolog has multiple inheritance, meaning that you can inherit from many classes simultaneously.

==Final Remarks==

Above I have introduced you to the most fundamental concepts of the object system in Visual Prolog. There are other interesting features in the object system, but these will not be covered here, for example:

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

*Object predicate values, a seamless counterpart to C# delegates.

==References==
[[ru:Введение в Классы и Объекты]]
[[Category:Tutorials]]

Turbo Prolog

2007-09-12T19:33:33Z

Kari Rastas: added an explanation an explanation for example codes

Turbo Prolog was marketed in the 80's by Borland. Turbo Prolog was created by the founders of PDC.

==Turbo Prolog example codes / programs in internet==

Turbo Prolog code can with relative little work be "translated" to Visual Prolog. So the old Turbo Prolog examples which can be found in Internet are worth studying.

[http://perso.orange.fr/colin.barker/tpro1/tpro.htm Colin Barker*s Turbo Prolog Goodies]

Frank Bergmann has several Turbo Prolog examples
*[http://www.fraber.de/games/chess/index.html Chess]
*[http://www.fraber.de/games/queens/index.html Queens]
*[http://www.fraber.de/games/world/index.html Tarskies World]

Turbo Prolog

2007-09-12T12:15:45Z

Kari Rastas: New page: Turbo Prolog was marketed in the 80's by Borland. Turbo Prolog was created by the founders of PDC. ==Turbo Proglog example codes / programs in internet== [http://perso.orange.fr/colin.ba...

Turbo Prolog was marketed in the 80's by Borland. Turbo Prolog was created by the founders of PDC.

==Turbo Proglog example codes / programs in internet==

[http://perso.orange.fr/colin.barker/tpro1/tpro.htm Colin Barker*s Turbo Prolog Goodies]

Frank Bergmann has several Turbo Prolog examples
*[http://www.fraber.de/games/chess/index.html Chess]
*[http://www.fraber.de/games/queens/index.html Queens]
*[http://www.fraber.de/games/world/index.html Tarskies World]