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

Exception Handling

2021-10-13T09:55:32Z

Kasper B H Petersen: /* Introduction to exception handling */

An exception is a deviation from the expected. What is an exception in one context may be expected in another context, and thus not an exception in that context.

In Visual Prolog programs exceptions are used to deal with deviations from what is expected in the given context. When a certain program part gets into a situation it cannot deal with it can '''''raise''''' an exception. When an exception is raised the program control is transferred to the nearest '''''exception handler'''''. If the exception handler cannot handle the exception it can either raise a new exception or '''''continue''''' the original exception.

The program will terminate with an error message if there is no exception handler to transfer the control to.

=== Introduction to exception handling ===

There are many concepts and entities to understand when dealing with exceptions. This section will give an introduction by means of an example.

A certain program needs to write some information to a file. Therefore it has a predicate <vp>writeInfo</vp> that can write this information. <vp>writeInfo</vp> calls the PFC constructor <vp>outputStream_file::create</vp> to obtain a stream that it can write the information to:

<vip>clauses
writeInfo(Filename) :-
S = outputStream_file::create(Filename),
…</vip>

But if the file already exists and is write-protected it is impossible to create the stream.

In <vp>outputStream_file::create</vp> this situation is considered to be exceptional/unexpected and therefore it raises an exception.

When an exception is raised the program control is transferred to the nearest exception handler, which can hopefully handle the situation and thus bring the program back on track again.

In this case <vp>writeInfo</vp> is called after the user have entered the file name in a dialog and pressed a '''Save'''-button. So the handling we want is simply to tell the user that the information was not written because the file was write-protected. The user can choose a different filename, remove the write protection, delete the file, cancel the operation entirely or something else. But from the program's point of view the exceptional situation is handled.

To set a handler we use the {{lang2|Terms|try-catch|try-catch}} language construction:

<vip>clauses
saveInfo(Filename) :-
try
writeInfo(Filename)
catch TraceId do
% <<handle situation>>
end try.</vip>

The code works like this: <vp>writeInfo</vp> is called, if it succeeds the {{lang2|Terms|try-catch|try-catch}} construction will not do more and <vp>saveInfo</vp> will also succeed.

But in the write-protected case <vp>outputStream_file::create</vp> will raise an exception and therefore the following will take place:

# <vp>TraceId</vp> will be bound to the (so called) '''''trace id''''', which is a handle to information about the exception (described in more details below)
# The handler code (i.e. the code between <vp>do</vp> and <vp>end try</vp>) is evaluated
# The result of the handler code will be the result of the {{lang2|Terms|try-catch|try-catch}} construction, and thus of <vp>saveInfo</vp>.

So for the "write-protected" exception the handler code should write a message to the user.

If it is another kind of exception the handler will have to do something different. Especially, it may be an exception that the handler does not know how to handle. In this case the best thing the handler code can do is to continue the exception as an ''unknown'' exception (i.e. unknown to the handler).

When an exception is continued it consists of the original exception plus some continue information. If it has been continued by several handlers it will contain a lot of continue information in addition to the original exception information. The exception information describes a trace from the point of raise through all the handlers. The <vp>TraceId</vp> variable that is bound in the {{lang2|Terms|try-catch|try-catch}} construction gives access information about the entire trace (hence the name).

As mentioned above the program will terminate with an error message, if an exception is raised and no handler can be found. Therefore programs normally setup an outermost default exception handler. <vp>mainExe::run</vp> setup such a handler in a console program this is the fall-back handler. In a GUI program there is also a default hander in the GUI event loop which will catch exceptions arising from the handling of an event.

All in all, the lifecycle of an exception is as follows:

* It is raised
* It is caught and continued
* It is caught and continued
* …
* It is caught and handled (or the program terminates with an error message)

Each time the exception is caught the trace so far can be examined. When the exception is raised and each time it is continued extra information can be added to the exception trace. If nothing else handles an exception it will (normally) be handled by the fallback/default handler of the program.

=== Defining an exception ===

An exception is a value of the type <vp>core::exception</vp>

<vip>domains
exception = exception(string ClassName, string ExceptionName, string Description).</vip>

I.e. an exception is a functor term that contains three pieces of information:

; <vp>ClassName</vp>
: The name of the class that defines the exception
; <vp>ExceptionName</vp>
: Then name of the exception typically the name of a constant in the program
; <vp>Description</vp>
: A description of the exception

{{example| The <vp>cannotCreate</vp> exception from the example above is declared in the class <vp>fileSystem_api</vp> like this:
<vip>class fileSystem_api
…
constants
cannotCreate : exception = exception(class_name(), constant_name(), "Cannot create or open the specified file").
…</vip>

[[Language_Reference/Built-in_entities/Predicates#class_name|<vp>class_name/0-></vp>]] and [[Language_Reference/Built-in_entities/Predicates#class_name|<vp>constant_name/0-></vp>]] are built-in predicate that returns the name if the class/constant in which the call occurs. So the line above is equivalent to this:
<vip>class fileSystem_api
…
constants
cannotCreate : exception = exception("fileSystem_api", "cannotCreate", "Cannot create or open the specified file").
…</vip>
}}

Many/most programmers will never need to define exceptions, because in many/most cases the exceptions to use are already defined. An exception definition is only needed when the exception must be distinguished from other kinds of exceptions, such that exception handlers can deal specially with that kind of exception. Typically exception definitions are only necessary for exceptions that are raised by library software. In most cases programmers will raise the exception <vp>internal_error</vp>.

=== Raising an exception ===

There are many predicates that explicitly raises exceptions, but most of them does it by calling a predicate in <vp>exception</vp>:

<vip>class exception
…
predicates
raise_exception : (exception Exception, ...) erroneous [programPoint].
raiseDetailes : (exception Exception, namedValue* ExtraInfo) erroneous [programPoint].
raise_definiteUser : (exception Exception, string Msg, namedValue* ExtraInfo) erroneous [programPoint].
...</vip>

In all cases the <vp>Exception</vp> is the exception to raise and the rest of the arguments provides additional information about the exception. See also [[Language Reference/Predicates#programPoint|programPoint in Language Reference]] for information about the programPoint attribute.

{{example|The <vp>cannotCreate</vp> exception from above is raised by the predicate <vp>fileSystem_api::raise_cannotCreate</vp>/<vp>fileSystem_api::raise_cannotCreate_explicit</vp>. The code looks like this:
<vip>clauses
raise_cannotCreate_explicit(ProgramPoint, FileName, LastError) :-
Desc = getLastErrorDescription(LastError),
Msg = string::format("Cannot create or open '%%%s'\nError = 0x%08x\n%%%s",
fileSystem_fileName_parameter, LastError, errorDescription_parameter),
raise_definiteUser_explicit(ProgramPoint, cannotCreate, Msg,
[namedValue(fileSystem_fileName_parameter, string(FileName)),
namedValue(fileSystem_path_parameter, string(directory::getCurrentDirectory())),
namedValue(errorCode_parameter, unsigned(LastError)),
namedValue(errorDescription_parameter, string(Desc))]).</vip>

<vp>raise_cannotCreate_explicit</vp> is called with the <vp>ProgramPoint</vp> of the raising predicate, the <vp>FileName</vp> and the windows error code <vp>LastError</vp> that the relevant low level Windows API predicate caused.

<vp>exception::getLastErrorDescription</vp> obtains the description corresponding to <vp>LastError</vp> from Windows.

<vp>exception::raise_definiteUser_explict</vp> is then used to raise the <vp>cannotCreate</vp> exception with the four pieces of extra information. The destinction between ''errors'', ''user errors'' and ''definite user errors'' are described below.
}}

It is very common to create helper predicates like <vp>fileSystem_api::raise_cannotCreate</vp> to do the actual raising rather that calling one of the predicates in <vp>exception</vp> directly from the code that needs to raise the exception. That way it is certain that the extra info for this particular exception is handled in the same way in all cases.

Normally, the helper raise predicate is created by the same programmer that declares the exception. And as mentioned above this is normally only programmers that create library software.

Application programmers will in most cases raise exceptions by calling appropriate raiser predicates, typically the some defined in <vp>exception</vp>.

=== Catching and handling exceptions ===

Exceptions are caught with the {{lang2|Terms|try-catch|try-catch}} construction:

<vipbnf>try <Body> catch <TraceId> do <Handler> end try</vipbnf>

If <vpbnf><Body></vpbnf> terminates with an exception <vpbnf><TraceId></vpbnf> is bound to the ''trace id'' and then <vpbnf><Handler></vpbnf> is evaluated.

<vpbnf><TraceId></vpbnf> is used to obtain information about the exception trace. This information can be used for at least two things:

* Determine which kind of exception that is caught, so that it can be decided if and how to handle it
* Obtain additional information to write to the user, in a log or use for something else

As explained above it is very common that an exception is continued one or more times after it has been raised, so an exception contains a complete ''trace'' of entries (raise, continue, continue, ---). Subsequently, you will need to search the trace to see if a certain exception is among the entries. This is done by calling <vp>exception::tryGetDescriptor</vp>:

<vip>predicates
tryGetDescriptor : (traceId TraceID, exception Exception) -> descriptor Descriptor determ.</vip>

The exception trace corresponding to <vp>TraceId</vp> is searched for an exception of the kind <vp>Exception</vp>. If there is such an entry in the trace (raised or continued) the corresponding exception descriptor is returned in <vp>Descriptor</vp>.

The predicate fails if such an exception is not in the exception trace.

The <vp>Descriptor</vp> contains the extra information about that particular entry in the exception trace:

<vip>domains
descriptor = descriptor(programPointDescriptor ProgramPoint, exception Exception,
kind Kind, namedValue* ExtraInfo, gmtTimeValue GMTTime, unsigned ThreadId).
</vip>

<vp>ProgramPoint</vp>
: A readable representation of the <vp>programPoint</vp> where the exception was raised/continued.
<vp>Exception</vp>
: The <vp>exception</vp> in question
<vp>Kind</vp>
: The entry kind (<vp>raise</vp> or <vp>continue</vp>)
<vp>ExtraInfo</vp>
: The extra information provided with this entry in the trace
<vp>GMTTime</vp>
: The time this exception trace entry was raised/continued
<vp>ExceptionDescription</vp>
: The exception description of this entry (this information is also present in <vp>ExceptionInfo</vp>)
<vp>ThreadId</vp>
: The thread id of the thread that raised/continued this entry

Much of this information is mainly interesting if the exception is not handled. The information that is most interesting when handling an exception is:

* The exception has been determined to be the one we expected
* The <vp>ExtraInfo</vp> for this entry is available for use in messages, etc

The predicate <vp>exception::tryGetExtraInfo</vp> is convenient for obtaining extra information:

<vip>predicates
tryGetExtraInfo : (descriptor Descriptor, string Name) -> value Value determ.</vip>

<vp>Descriptor</vp>
: Is the description whose extra info we want to get something from.
<vp>Name</vp>
: The name of the extra info parameter we want to obtain.
<vp>Value</vp>
: The value that the mentioned parameter has.

{{example| Code for catching and handling the <vp>fileSystem_api::cannotCreate</vp> exception can look like this:

<vip>clauses
saveInfo(Filename) :-
try
writeInfo(Filename)
catch TraceId do
if D = exception::tryGetDescriptor(TraceId, fileSystem_api::cannotCreate) then
stdio::write("Cannot write to the file: ", Filename),
if string(Description) = exception::tryGetExtraInfo(D, exception::errorDescription_parameter) then
stdio::writef("; %", Description)
end if,
stdio::write("\n")
else
exception::continue_unknown(TraceId, "Filename = ", Filename)
end if
end try.</vip>

The code here don't need to obtain the <vp>fileSystem_exception::fileName_parameter</vp>, because the file name is already known in the <vp>Filename</vp> variable.

But we can obtain Window's description of the problem querying for <vp>common_exception::errorDescription_parameter</vp>

We '''continue''' the exception as unknown if it is not a <vp>cannotCreate</vp> exception. For the continue call we add the filename as additional information. <vp>common_exception::continue_unknown</vp> will create a string of the extra arguments and add it as an <vp>common_exception::errorArguments_parameter</vp>. Such information is mainly for use in the default exception handler to be discussed below.
}}

=== Exception dumps ===

The class <vp>exceptionDump</vp> contains predicates for dumping exception traces to <vp>stdio</vp>, some other <vp>outputStream</vp> or a <vp>string</vp>.

An exception dump contains three major pieces of information:

* A dump of the call stack (with file names and line numbers) from the point where the exception was raised
* A dump of the exception-trace with all the information from the exception descriptors
* Information about the operating system that the program ran on

<vp>exceptionDump</vp> have predicates both for dumping exception traces both from a <vp>traceId</vp> and from a <vp>traceInfo</vp> obtained with <vp>exception::getTraceInfo</vp> (see [[#Serializing exceptions]] below).

Dumps for a certain program are in general only useful to the programmers of that program; the users of the program will find dumps cryptic and rather uninteresting. I.e. the purpose of dumps is to give the programmer means for improving the program.

=== Default handling ===

A program should handle all exceptions, because if an exception is continued or raised at a point where there is no handler the program will terminate with a rather bad error message. The error message is bad because most exception handling is done in PFC; the language itself knows nothing about exception traces and the like.

To be sure that all exceptions are handled it is normal to set up a default (or fallback) exception handler.

<vp>mainExe::run</vp> (and <vp>mainExe::runCom</vp>) which is normally called in the goal setup such a default exception handler: It runs the <vp>main::run</vp> predicate inside a {{lang2|Terms|try-catch|try-catch}} construction that will handle any exception.

The handler in <vp>mainExe::run</vp> (and <vp>mainExe::runCom</vp>) dumps the entire exception trace to output stream in <vp>stdio</vp>. And then the program will terminate. The idea is that:

* Perhaps the user can see something from the dump (which may for example say that ''access is denied'' to ''xxx.txt'')
* Alternatively, the developer of the program may use the dump to improve the program

In addition to the handler in <vp>mainExe::run</vp> a GUI program also set a default handler in the event loop. This handler is set by calling <vp>applicationWindow::setErrorResponder</vp>:

<vip>domains
errorResponder = (applicationWindow Source, exception::traceId TraceId).

predicates
setErrorResponder : (errorResponder Responder).</vip>

By default the error responder <vp>errorPresentationDialog::present</vp> is used. The functioning of the <pv>errorPresentationDialog</vp> is closely related to a categorization of exceptions described in the next section.

PFC place exceptions in three major categories based on who is (believed to be) responsible:

; Internal errors
: An exceptional state which the programmer is responsible to deal with
; User exception
: An exception which can perhaps be solved by the end user of the program, but which may also call for a programmer solution. User exceptions carries a message for the end user of the program.
; Definite user errors
: An exception which is definitely one the end user should deal with, because the programmer cannot do anything about it anyway

You may notice that "error" is used to signal that a person is (believed to be) responsible for the problem, where as "exception" also covers situations with looser relation to specific persons (such as a network failure).

==== Internal errors ====

Internal errors are caused and/or should be prevented by the programmer of the program.

{{Example| A predicate takes two lists as argument and pair the elements of the lists. So the lists are expected to have the same length. If the lists have different lengths it is appropriate to raise an <vp>internal_error</vp>, because it is clearly the responsibility of the programmer to ensure that the lists have same length; the end-user of the program can at most influence this indirectly.
}}

==== User exceptions ====

User exceptions typically deal with problems related to external resources such as files, network, databases, web servers, etc. Often the user will become wiser by being informed about the problem and often the user may even solve the problem.

{{Example| The read-only file problem discussed above is a typical example of a user exception. It is the user rather than the programmer that can solve the problem with the read-only file.
}}

A user exception is distinguished by having extra information in a field with name <vp>common_exception::userMessage_parameter</vp>. This extra info should be a message with relevance for an end user of the program. The message can reference other extra info parameters using the format %PARAM. The preferred way to raise user exceptions is by means of the predicate <vp>exception::raise_user</vp>. Likewise you can continue exceptions with a user message using <vp>exception::continue_user</vp>.

{{Example| This predicate will raise a '''''user''''' <vp>fileSystem_api::cannotCreate</vp> exception

<vip>class predicates
raise_cannotCreate : (string Filename) erroneous.
clauses
raise_cannotCreate(Filename) :-
exception::raise_user(fileSystem_api::cannotCreate,
"It is not possible to create the file %Filename",
[namedValue("Filename", string(Filename))]).</vip>

The use of <vp>"%Filename"</vp> in the message corresponds to the extra info <vp>"Filename"</vp>.
}}

The predicate <vp>exceptionDump::tryGetUserMessage</vp> will return a user message from a <vp>traceId</vp> if possible. The message will consist of all user messages from the entire trace and will have parameters substituted.

{{Example| Given <vp>raise_cannotCreate</vp> from above and calling <vp>test</vp>:

<vip>clauses
test() :-
try
raise_cannotCreate("test.xxx")
catch TraceId do
if UserMsg = exceptionDump::tryGetUserMessage(TraceId) then
stdio::write(UserMsg)
end if
end try.</vip>

The following message is written to <vp>stdio</vp>:

<source lang="text">It is not possible to create the file test.xxx</source>
}}

==== Definite user errors ====

Definite user errors are exceptions that are solely the responsibility of the user of the program. For example wrong use of the program.

{{Example| A program can write out some information, but only if the user has specified which information to write. So if the user invoke the functionality without having specified which information to write, it is appropriate to raise a definite user error.
}}

A definite user exception is distinguished by adding <vp>true</vp> as extra info for the parameter <vp>exception::definiteUserError_parameter</vp>. The preferred way to do this is by using the predicates:

* <vp>exception::raise_definiteUser</vp>
* <vp>exception::continue_definiteUser</vp>

The use of these predicates is the same as the user of <vp>common_exception::raise_user</vp> and <vp>common_exception::continue_user</vp>.

An exception trace is considered a definite user error if one (or more) entries in the trace carries the <vp>exception::definiteUserError_parameter</vp>. The predicate <vp>exception::isDefiniteUserError</vp> will succeed for definite user errors.

=== Serializing exceptions ===

In some situations the best way to handle an exception is by sending all the information about the exception somewhere else. A server might for example want to send the information to the client program that caused the exception, because then there is a user that can take action.

A <vp>traceId</vp> only have a meaning in the process that has created it, but the predicate <vp>exception::getTraceInfo</vp> can create a <vp>traceInfo</vp> structure (<vp>TraceInfo</vp>) from the <vp>traceId TraceId</vp>:

<vip>predicates
getTraceInfo : (traceId TraceId) -> traceInfo TraceInfo.</vip>

Such a structure is a functor structure that can be serialized/deserialized with <vp>toString</vp>/<vp>toTerm</vp>; <vp>write</vp>/<vp>read</vp>; nested in a fact database using <vp>save</vp>/<vp>consult</vp>; etc.

==== Packed Exceptions ====

Sometimes, e.g., in a client/server application, you catch an exception on the server which you want to handle on the client. In that case you can serialize the exception on the server send it to the client and reraise it as a packed exception.

On the server
<vip>
try
...
catch E do
sendExceptionToClient(exception::getTraceInfo())
end try,
...
</vip>

On the client
<vip>
...
Rtn = remoteCall(...),
if error(TraceInfo) = Rtn then
exception::raise_packed(TraceInfo, "remoteCall returned an exception")
end if
...
</vip>

The predicate <vp>raise_packed</vp> works like a <vp>continue_unknown</vp> but continues a serialized exception instead of normal exception. It is meant to be used when the exception stem from another program and thus only is available in serialized form.

=== The error presentation dialog ===

The error presentation dialog (in the class <vp>errorPresentationDialog</vp>) is by default used by the default exception handling in a GUI program. Its behavior is closely related to the classification of exceptions described above, as described by these two rules:

* If the exception trace carries a user message, this message will be presented to the user.
* If the exception trace is not a definite user error, there will be information for the programmer

So if the exception is an internal error there will only be information for the programmer; if it is a user exception there will both be information for the user and for the programmer; and if it is a user error there will only be information for the user.

If there is information to the programmer the exception dialog will have a details/less details button that can show/hide the programmer information. It will also have a "report error" button, which by default will copy the information to the clipboard so that the user can easily send it to the programmer.

[[Image:ErrorPresentationDialogDefault.png]]

The dialog is customizable by means of various properties:

<vip>properties
title : string. % := "Error".
callBackBtnText : string. % := "&Copy".
dontCallBackBtnText : string. % := "&OK".
showDetailsBtnText : string. % := "Show &Details".
hideDetailsBtnText : string. % := "Hide &Details".
closeApplicationBtnText : string. % := "Close &Application".
commentTextPromt : string. % := "Please describe what you were doing when the error occured:"
internalErrorMessage : string. % := "An internal error has occurred.\nPlease send a bug report to your vendor.".
feedbackMessage : string. % := "Please send your feedback.".
definiteUserErrorIcon : vpiDomains::resid.
userErrorIcon : vpiDomains::resid.
internalErrorIcon : vpiDomains::resid.
reportErrorDelegate : reportErrorDelegate.
extraInfoWriter : writer.</vip>

All texts and labels are controlled by properties.

The <vp>extraInfoWriter</vp> is a callback that can be set to include extra info for the programmer. This information will both be presented in the details window and reported back to the programmer if the user press the "report error" button (i.e. the button which is by default labeled '''Copy''').

The <vp>extraInfoWriter</vp> callback predicate must have this type:

<vip>domains
writer = (outputStream Stream).</vip>

The dialog will invoke the predicate and then it should simply write extra information to the received stream.

{{Example| The Visual Prolog IDE uses the <vp>extraInfoWriter</vp> to write version information, information about the open project and information about the last actions carried out in the IDE. This information will help the programmers to analyze the problem.
}}

The action performed by the "report error" button is customizable using the property <vp>reportErrorDelegate</vp>, which is a callback predicate of this type:

<vip>domains
reportErrorDelegate = (window Parent, string Comment, optional{exception::traceInfo} TraceInfo, string ExtraInfo).</vip>

; <vp>Parent</vp>
: The error presentation dialog which can be used as parent for additional dialogs.
; <vp>Comment</vp>
: The users comment from the comment box.
; <vp>TraceInfo</vp>
: If the dialog is invoked on an exception the trace info is here, if it is invoked for feedback this value is <vp>none</vp>
; <vp>ExtraInfo</vp>
: The extra info written by the <vp>extraInfoWriter</vp> callback

{{Example| In the Visual Prolog IDE the <vp>reportErrorDelegate</vp> will send the exception information to a WEB service which will insert the notification in a database. The notifications in the database will then be used to improve the IDE.
}}

[[Category:Tutorials]]

Language Reference/Objects and Polymorphism

2021-10-12T09:57:39Z

Kasper B H Petersen: /* Subsumption polymorphism */

{{languageReferenceNavbar|Generic Interfaces and Classes}}

The programming language Visual Prolog has gone through a huge development in the latest years, and this will also continue in future. Most noticeable is the shift to object-orientation, and the introduction of parametric polymorphism. In this paper we will explain the reason for introducing these features. Examples will be used to illustrate how these facilities can help to tackle the increasing complexity and size of software.

=== Motivation ===

While Prolog has many great virtues, one must remember that it is from the IT-bronze-age, and it would be silly to think that it would stay contemporary after three decades or more, especially considering the speed with, which the IT-world has evolved since then. Back then you could write an amazing Prolog program that described how to get a cabbage, a goat, a wolf and a farmer across a river in a little boat without anybody eating anybody. You can still write such programs just as easily (see [[Farmer, Wolf, Goat and Cabbage]]), but they are just not that amazing anymore. Show it to your children and they will immediately ask why the solution is not an animation, and explain that there are millions of much more advanced programs one click away on the Internet already.

Programs today must be more advanced than yesterday. They also have to live and interact with a much larger world than yesterday. And this is an ongoing story.

Many attempts has been made to help tackle these challenges; we have chosen to add the elements that we believe are the winners to Visual Prolog. These are especially object-orientation and parametric polymorphism, but there are also other new elements especially taken from the functional programming world.

=== Goals and Means ===

The goals of the language update is to provide better means for creating and maintaining more complex programs for more complex surroundings.

==== Simplicity ====

Humans are better to dealing with simple things than complex things, so one important way to deal with complexity is to reduce it to something simpler, especially by using "structure" to organize the complexity.

The main "trick" is the ''divide and conquer '' principle: Divide the original problem into separate sub-problems that can be solved individually. I.e., the solution to the overall problem consists of a number of sub-solutions and something that combines these into the overall solution.

==== Maintainability ====

For software it is often not enough to solve a problem, we must also be able to maintain and extend the solution in an evolving world. So it is important that the used methods not only solve the problem, but also result in a program that can be maintained. Here it is important that the program is understandable and especially that the ''divides'' are visible and clear in the program.

==== Reuse and sharing ====

When you divide problems into sub-problems, perhaps repeatedly, you will sometimes see similar sub-problems. Then it would of course be nice to short cut by reusing a similar solution. Such a solution can be adopted into the new context, but there are two ways this can happen. We can make a copy and update it to its new purpose, or we can try to share the code between the two problems.

The latter is clearly the hardest and only makes sense if both pieces of software are still maintained. But in that case you will have the advantage that maintenance made in one context is also shared with the other context.

==== Flexibility ====

It is also desirable that your software is flexible. You may for example need to deliver several variants of your software to different customers. Or you may need to reconfigure the software to a changed context. Also some of your shared sub-solutions may need to go into contexts that are not completely the same.

==== Power ====

Finally, it is of course desirable if language extensions add additional programming power. For example, by simplifying the code necessary to tackle certain standard "issues".

=== Polymorphism ===

Visual Prolog has been extended with many language features that support the goals above, but it is still up to the programmer to apply these features such that the goals are achieved. Here we will focus on understanding and using polymorphism.

The object-system in Visual Prolog gives so called ''subsumption polymorphism'' and also have ''parametric polymorphism''. Polymorphism is especially well-suited for ''divide and conquer'' that supports ''sharing'' of code.

==== Subsumption polymorphism ====

An object is a closed entity that carries state and code. The object provides an interface through which the surroundings can interact with the object. The object can also interact with other objects through their interfaces.

Each interface has an explicit definition in the source code. The definition effectively consists of a name and a number of predicate declarations.

Let us assume that we want an object through which some administrative system can report salary. In an oversimplified world, such an object might have this interface:

<vip>
interface salarySystem
predicates
salary : (string Name, real Amount).
end interface salarySystem
</vip>

An object with this interface will allow you to report an <vp>Amount</vp> for a person (identified by <vp>Name</vp>).

The salarySystem interface defines a data type that can be used in the program. The main salary reporting predicate in the application might be declared like this:

<vip>
class predicates
reportSalary : (salarySystem SalarySystem).
</vip>

For the sake of the example, we simply hard code a little salary reporting like this:

<vip>
clauses
reportSalary(SalarySystem) :-
SalarySystem:salary("John D", 135.12),
SalarySystem:salary("Elvis P", 117.00).
</vip>

We will of course also need to implement our salary system objects, and that is where the subsumption polymorphism comes in play. The thing is that our customers of course use a lot of different salary systems, which must receive input in many different formats and using many different media. Objects are implemented by classes, and the fortunate thing is that many different classes can implement the same interface. Objects produced by any such class can be used by the reportSalary predicate. Thus, the reportSalary predicate is ''polymorphic'' because the <vp>salarySystem</vp> type '' subsumes'' all the different implementations of the interface. To deal with the ACME salary system we declare this class:

<vip>
class acme : salarySystem
end class acme
</vip>

The declaration simply says that <vp>acme</vp> is a class that produces objects of type salarySystem. The class also needs an implementation:

<vip>
implement acme
constants
fmt = "SAL:%>>>%\n".
clauses
salary(Name, Amount) :-
stdio::writef(fmt, Name, Amount).
end implement acme
</vip>

To illustrate the polymorphism, we will also implement the integration to the O'Salery system. Again we declare and implement a class:

<vip>
class oSalary : salarySystem
end class oSalary

implement oSalary
constants
fmt = "<salary name=\"%\" wage=\"%\" />\n".
clauses
salary(Name, Amount) :-
stdio::writef(fmt, Name, Amount).
end implement oSalary
</vip>

Now let us try our two salary system integrations:

<vip>
clauses
test():-
ACME = acme::new(),
reportSalary(ACME),
Osalery = oSalary::new(),
reportSalary(Osalery).
</vip>

In the test predicate above, we create one of each salary systems and report salary to them. The result looks like this:

<vip>
SAL:John D>>>135.12
SAL:Elvis P>>>117
<salary name="John D" wage="135.12" />
<salary name="Elvis P" wage="117" />
</vip>

In this example, the difference was not that big, but we might also have placed the result in a database, used a foreign API, called a WEB service or whatever.

The solution above uses the divide and conquer principle to separate the reporting in a vendor independent part and a vendor specific part. In this case the vendor independent part also deals with the company level in the reporting, were as the vendor dependent part only deals with the person level.

We have used subsumption polymorphism to provide the flexibility to deal with many different salary systems in a seamless way. In real world, this may not be as simple as here though. The key to success is that the salarySystem interface is a sufficiently powerful abstraction/generalization of ''all'' the relevant salary systems. It may for example be necessary to provide several different ways to identify persons in the salary predicate. Different salary systems can then use the identification method, which is appropriate for them and ignore the rest.

The reportSalary predicate is ''shared'' across different salary systems. The sharing is a high-level domain specific sharing, within the same application or variants of it.

Visual Prolog also has another kind of subsumption polymorphism: Predicate values. A predicate value is a predicate that is bound to variables, transferred as parameter and/or stored in facts. Again, the polymorphism comes from a type that ''subsumes'' many different implementations.

As an example, PFC uses predicate values in its heavily used ''event notification scheme''. A scheme that can of course also be used outside PFC.

The event notification scheme has two kinds of actors: the event source and the event listener. There is one event source, but there can be any number of listeners. The event source offers predicates for registering and deregistering event listeners. When the event occurs all registered listeners are notified.

The interesting thing is that the event listener is a predicate, meaning that the notification will immediately execute code. In addition, due to the subsumption polymorphism each listener can have its own implementation and thus perform quite different actions.

A very important property of predicate values is that they can be '''''object''''' predicates, and that these have access to the object state to which they belong.

We shall not describe the event notification scheme in details here, though it is good to understand. The reader is encouraged to study the concept in PFC (look for ''addXxxxListener''). However, the use of predicate values will be exercised in the job-scheduling example in the end of this paper.

==== Parametric Polymorphism ====

Like for subsumption polymorphism the purpose of ''parametric'' polymorphism is to use the same code for many things. However, where subsumption polymorphism is mainly about supplying different implementations to the same context, parametric polymorphism is mainly about using the same implementation in different contexts.

Let us start with a very simple example, to introduce the concepts. We will implement a function, which takes the list as argument and returns the elements one by one (non-deterministically).

In Visual Prolog the list domain is a polymorphic domain: If Elem is a type/domain then Elem* the list domain of Elem. The new thing is that ''parameters'' like Elem and type expressions like Elem* can be used in declarations, and that the resulting declaration will cover any instantiation of such parameters.

Therefore we can declare our getMember_nd function like this:

<vip>
predicates
getMember_nd : (Elem* List) -> Elem Value
nondeterm.
</vip>

This declaration says that <vp>getMember_nd</vp> is a function, which takes a list of Elem argument and returns an Elem, where Elem is any domain/type.

The implementation is straightforward:

<vip>
clauses
getMember_nd([V|_L]) = V.
getMember_nd([_V|L]) = getMember_nd(L).
</vip>

Without further notice <vp>getMember_nd</vp> can be used on any list kind:

<vip>
clauses
run():-
console::init(),
L = [[1,2,3], [7,-7], [9,4,5]],
foreach X = list::getMember_nd(L) do
stdio::writef("X = %\n", X)
end foreach.
</vip>

Here <vp>Elem</vp> is <vp>integer*</vp> (i.e. list of integers). The output looks like this:

<vip>
X = [1,2,3]
X = [7,-7]
X = [9,4,5]
</vip>

The list domain is a predefined polymorphic domain. But you can also define polymorphic domains yourself. As an example we can create a ''priority queue''; sometimes called a heap. Let me warn you, the implementation I will use here is not particularly efficient; it is just simple.

The idea of the priority queue is that we can insert some data with a priority, later we can then retrieve the data with lowest priority. It sounds a bit strange, that it is the one with the lowest Priority that is retrieved; but that is how it normally works. I assume that it comes from the idea of first priority, second priority, etc. where smaller number means higher priority.

Anyway, in this case we want to implement the queue as a list of tuple's, each tuple has two elements the first is the priority and the second is the Data. Furthermore, we will keep the list sorted after priority (i.e. an invariant), such that the smallest element is always first in the list.

'''tuple''' is already defined in Visual Prolog its definition looks like this:

<vip>
domains
tuple{T1, T2} = tuple(T1, T2).
</vip>

There are also tuple's with other arities, but we only need the pair. This is an example of a programmer defined polymorphic domain. What the definition says is that tuple is a domain with two type parameters <vp>T1</vp> and <vp>T2</vp>. You may think of it as an infinite family of domains corresponding to all instantiations of the type parameters, e.g.:

<vip>
domains
tuple_char_char = tuple(char, char).
tuple_char_integer = tuple(char, integer).
tuple_char_string = tuple(char, string).
...
</vip>

The single domain definition above corresponds to all these domains, but actually the domain names/expressions look like this:

<vip>
tuple{char, char}
tuple{char, integer}
tuple{char, string}
...
</vip>

The values looks as expected; let us take a relatively complex one right away:

<vip>
X = tuple(tuple('a',"a"), [1.2])
</vip>

T2 is a tuple, its first element is itself a tuple (containing a char and a string), its second element is a list of real's. Subsequently, X has this type:

<vip>
tuple{ tuple{char, string}, real* }
</vip>

As you can see type expressions can become rather complex. You will probably soon get use to this, but below I will show a little scheme that can be used to keep type expressions simpler and more understandable, and which will at the same time make your program more type safe.

We are now ready to define our queue domain:

<vip>
domains
queue_rep{Priority, Data} = tuple{Priority, Data}*.
</vip>

The <vp>_rep</vp> in the domain name has to do with the scheme mentioned above, right now you can simply ignore it. The domain definition says that <vp>queue_rep</vp> is a domain with two type parameters <vp>Priority</vp> and <vp>Data</vp> furthermore it is a list of tuple's of these types.

You may wonder why <vp>Priority</vp> is a type parameter, you may think that it should have been a number type like integer. However, in Visual Prolog all data types are ordered, and therefore any data type can be used as a priority. Using a type parameter here makes the resulting queue more flexible. And at least I do not have to choose whether the priority should be integer, unsigned or real.

To know whether you can use a type parameter or have to use a regular type you will have to consider what you need from the type. Like here where we need ordering (comparison). The following is possible on type parameters:

*transferring as parameter
*binding and unifying (with values of same type)
*comparing (with values of same type)
*writing on streams
*reading from streams

The last thing is partially wrong, the compiler allows this, but in practice you cannot read all kind of data, it is for example not possible to read predicate values and objects from streams.

Let us return to our priority queue. Now that we have defined the domain that represents the queues, we will also have to declare and implement the suitable operations.

Let us start with the simple ones. First we need an operation to obtain the least element in the queue (i.e. the one with least priority). This can be declared like this:

<vip>
predicates
tryGetLeast_rep : (queue_rep{Priority, Data} Queue) -> tuple{Priority, Data} Least determ.
</vip>

The predicate is <vp>determ</vp> because the queue might be empty. The predicate is a function whose argument is a priority queue and which returns a tuple containing both the <vp>Priority</vp> and the <vp>Data</vp>. It does not remove the element from the queue, because I want to be able to peek at the element without removing it.

The list is sorted with the least element first, so the implementation is trivial:

<vip>
clauses
tryGetLeast_rep([Least|_]) = Least.
</vip>

Similarly we need a predicate for removing the least element:

<vip>
predicates
deleteLeast_rep : (queue_rep{Priority, Data} Queue1) -> queue_rep{Priority, Data} Queue.
clauses
deleteLeast_rep([]) = [].
deleteLeast_rep([_Least|Rest]) = Rest.
</vip>

Finally, we need an insert predicate:

<vip>
predicates
insert_rep : (queue_rep{Pri, Data} Q1, Pri P, Data D) -> queue_rep{Pri, Data} Q0.
clauses
insert_rep([], Pri, Data) = [tuple(Pri, Data)].

insert_rep(Q1, Pri, Data) = Q0 :-
[tuple(P1,D1)|Rest] = Q1,
if Pri <= P1 then
Q0 = [tuple(Pri, Data)| Q1]
else
Q0 =
[tuple(P1,D1) | insert_rep(Rest, Pri, Data)]
end if.
</vip>

I have chosen shorter variable names to make the code fit the narrow column, but at the same time it gives me the opportunity to explain that type variables like Pri above only have scope in the declaration/definition where they occur. Therefore, there is nothing wrong with using Priority in one declaration and Pri in another. Nevertheless, you should of course choose variable names with care, because good names make the code clearer. The compiler would not mind if you exchange Priority and Data, but I am sure that it could confuse many programmers.

The priority queue above can be used for various purposes, but it has two disadvantages, which both relate to the way we have defined the queue domain itself:

<vip>
domains
queue_rep{Priority, Data} = tuple{Priority, Data}*.
</vip>

A definition like this one is just an abbreviation or synonym, so <vp>queue_rep{integer, sting}</vp> is exactly the same as <vp>tuple{integer, string}*</vp>.

#The debugger will always show the unfolded type (i.e. <vp>tuple{integer, string}*</vp>) and this can be rather confusing.

#Any piece of data that have this type can accidentally be given as argument to the priority queue predicates. However, the priority queue operations not only require that the data has this type, it also expect that it is sorted in a specific way (i.e. that the data satisfies the invariant).

The latter problem could just as easy exist without polymorphism. It comes from using a general data structure for something specific. If you do this, you can mix anything that is of the general kind even though it is of different specific kinds.

So instead we just consider the queue_rep domain as being the internal ''representation'' of the queues, hence the extension _rep. To the external world we will wrap each queue_rep queue inside a functor.

Therefore, to the real queue domain will look like this:

<vip>
domains
queue{Priority, Data} = queue(queue_rep{Priority, Data}).
</vip>

Such a domain is neither an abbreviation nor a synonym.

The exported/public predicates will of course work on queue 's, so the complete class declaration looks like this:

<vip>
class priorityQueue
open core

domains
queue_rep{Priority, Data} = tuple{Priority, Data}*.

domains
queue{Priority, Data} = queue(queue_rep{Priority, Data}).

constants
empty : queue{Priority, Data} = queue([]).

predicates
insert : (queue{Pri, Data} Q1, Pri Pri, Data Data) -> queue{Pri, Data} Q0.

predicates
tryGetLeast : (queue{Priority, Data} Queue) -> tuple{Priority, Data} Least determ.

predicates
deleteLeast : (queue{Priority, Data} Queue1) -> queue{Priority, Data} Queue.
end class priorityQueue
</vip>

I have also added an empty queue constant to the class. As a user of the class you then do not need to be concerned with the representation of the queues at all, there are predicates and constants for everything.

The predicates in this class are very simple to implement given the predicates we implemented before, the only thing they should do is to remove and add the queue functor in the relevant places:

<vip>
clauses
insert(queue(Queue), Priority, Data) = queue(insert_rep(Queue, Priority, Data)).

clauses
tryGetLeast(queue(Queue)) = tryGetLeast_rep(Queue).

clauses
deleteLeast(queue(Queue)) = queue(deleteLeast_rep(Queue)).
</vip>

Using this _rep scheme is a bit less efficient, because of the extra functor, and it is entirely up to your temperament whether to use it or not. In any case it makes your type unique, rather than being a synonym type.

Priority queues can be used like this:

<vip>
clauses
test():-
Pq1 = priorityQueue::empty,
Pq2 = priorityQueue::insert(Pq1, 17, "World"),
Pq3 = priorityQueue::insert(Pq2, 12, "Hello"),
Pq4 = priorityQueue::insert(Pq3, 23, "!"),
stdio::writef("%\n", Pq4).
</vip>

The output looks like this (except for additional white space):

<vip>
queue( [tuple(12,"Hello"), tuple(17,"World"), tuple(23,"!") ] )
</vip>

It may seem that polymorphism disables type check, but in fact it gives a very strong but flexible type check. If, for example, I write:

<vip>
clauses
test():-
Pq1 = priorityQueue::empty,
Pq2 = priorityQueue::insert(Pq1, 17, "World"),
Pq3 = priorityQueue::insert(Pq2, 12, 13).
</vip>

Then I will get the error message:

error c504: The expression has type '::integer', which is incompatible with the type '::string'

The first insert forces the Data type of Pq2 to be string, therefore you cannot use an integer in the next line.

What may be more surprising is that it also forces the Data type of Pq1 to be string. Therefore this code gives exactly the same error:

<vip>
clauses
test():-
Pq1 = priorityQueue::empty,
Pq2 = priorityQueue::insert(Pq1, 17, "World"),
Pq3 = priorityQueue::insert(Pq1, 12, 13).
</vip>

On the other hand this is legal:

<vip>
clauses
test():-
Pq1a = priorityQueue::empty,
Pq2 = priorityQueue::insert(Pq1a, 17, "World"),
Pq1b = priorityQueue::empty,
Pq3 = priorityQueue::insert(Pq1b, 12, 13).
</vip>

The "moral" is that the constant empty is polymorphic, but variables can only have a monomorphic type, so when empty is bound to a variable a concrete type is chosen and "frozen".

The priority queue above can be use for numerous purposes. And the code can be shared between all such uses, both within a single program and across programs. If I choose to make a more efficient solution to the priority queue, then I will benefit from this in all places where it is used.

Parametric polymorphism is used to solve different problems in the same way (e.g. a using priority queue), and as such it is often used to make basic library software.

Subsumption polymorphism is in many respects the complement to parametric polymorphism: it is used solve the same problem in '' different'' ways (e.g. reporting salaries to ''different'' salary systems), and as such it is often used at high levels in applications to deal with variance.

However, the world is not black and white in this respect, there are many graduations and clear exceptions to this.

=== Example: Job Scheduler ===

Now let us try to combine some of the things from above to produce a simple, but yet powerful '''''job scheduler'''''.

A ''job'' is just some computation that should be performed. You register a job in the scheduler; the scheduler will then start the job at the requested time. Given such an "alarm clock" scheduler it is relatively easy to deal with reoccurring jobs and jobs that start in X minutes rather than at a certain time, and so forth. Here we will only consider the "alarm clock" functionality.

The scheduler will rely on a timer event: every time the timer even triggers it will see if any jobs are due, and execute these.

In this example I will just assume that time is an integer. I might want to use several schedulers in my program, so I choose to represent each scheduler by an object. Therefore the scheduler is mainly described as an interface, i.e. the type of the scheduler objects. The declaration of the scheduler looks like this:

<vip>
interface scheduler
domains
job = (integer Time) procedure (i).

predicates
registerJob : (integer Time, job Job).

predicates
timerTick : (integer Time).
end interface scheduler
</vip>

A job is a predicate value acting as a callback. I have chosen that the job receive the invocation Time as a parameter. This is mainly for illustrative purposes and simplicity. In real life, I would probably rather give it the scheduler, which I would enrich with predicates for obtaining the current time and probably other things as well. That way the job can itself decide which information it wants to obtain.

registerJob has the obvious functionality.

timerTick should be invoked regularly, since this is the heart of the scheduler.

The implementation looks like this:

<vip>
implement scheduler
open core, priorityQueue
facts
jobQueue : queue{integer, job}.

clauses
new() :-
jobQueue := empty.

clauses
registerJob(Time, Job) :-
jobQueue := insert(jobQueue, Time, Job).

clauses
timerTick(Time) :-
if
tuple(T, Job) = tryGetLeast(jobQueue),
T <= Time
then
Job(Time),
jobQueue := deleteLeast(jobQueue),
timerTick(Time)
end if.
end implement scheduler
</vip>

Most of the implementation is completely trivial. The main thing is that I use a priority internally for storing the jobs, with the time as priority. This have the advantage that the "most due" job is always easily accessible.

There is a jobQueue fact that is initialized in the constructor, and registerJob simply insert the job in the priority queue.

The important things take place in timerTick. It peek at the "least" job in the queue. If this hob should be started now or earlier then it is stated and removed from the queue, and then the rest of the queue is considered.

If the "least" job is not due then we do nothing, i.e. then we wait for another timer tick.

Before we use the scheduler I want to point out that several good reasons why the scheduler does not contain the actual timer:

*It may be important to be in synchronization with some external clock

*In some contexts the increment in the Time parameter need not be the same al the time

*In some contexts the Time does not relate to real time. (E.g. game steps, workflow steps., etc).

*In a GUI application it may be important that the timerTick's are invoked from a window event. I.e. to keep the application single threaded.

Using external timer ticks makes all this possible.

Let us use the timer in a console program, where the clock is provided by a simple for loop:

<vip>
class predicates
traceJob : (integer Time).
clauses
traceJob(Time) :-
stdio::write("Now: ", Time, "\n").

clauses
test() :-
Scheduler = scheduler::new(),
Scheduler:registerJob(500, traceJob),
foreach Time = std::fromTo(1,1000) do
Scheduler:timerTick(Time)
end foreach.
</vip>

The traceJob simply writes the clock. We create a scheduler and register the traceJob for running at Time = 500, and then we start the clock.

We can also make a job that reschedules itself and thus runs repeatedly. To do this the job must have access to the scheduler and therefore we save it in a fact:

<vip>
class predicates
cyclicJob : (integer Time).
clauses
cyclicJob(Time) :-
stdio::write("Hello World!\n"),
scheduler:registerJob(Time+50, cyclicJob).

class facts
scheduler : scheduler := erroneous.
clauses
test() :-
scheduler := scheduler::new(),
scheduler:registerJob(5, cyclicJob),
foreach Time = std::fromTo(1,200) do
scheduler:timerTick(Time)
end foreach.
</vip>

In the scheduler we have clearly used the (parametric) polymorphic priority queue. We have also used the (subsumption) polymorphism that comes from predicate values, such that we can register jobs with different implementation in the scheduler. The parametric polymorphism has exploited the homogeneous treatment of prioritizing things, no matter which kind of things we are dealing with. The subsumption polymorphism has been used to deal with the heterogeneous nature of jobs themselves.

[[ru:Объекты и полиморфизм. Ч.1]]

Lists and Recursion

2021-10-11T12:42:10Z

Kasper B H Petersen: /* Finding All the Solutions at Once */

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 <vp>1</vp>, <vp>2</vp>, and <vp>3</vp> 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 <vp>[1, 2, 3]</vp> is different from the list <vp>[1, 3, 2]</vp>.

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>

== Lists Domains ==

It <vp>T</vp> is a type/domain then <vp>T*</vp> is the domain of lists containing <vp>T</vp> elements. I.e. an asterisk after a domain means "List of that domain".

The elements in a list can be anything, including other lists. However, all elements in a list must belong to the '''''same''''' domain.

== 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 (<vp>[]</vp>).

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,
<vip>[a, b, c]</vip>
is equivalent to
<vip>[a | [b, c]]</vip>
which continuing the process is equivalent to
<vip>[a | [b | [c]]]</vip>
which is equivalent to
<vip>[a | [b | [c | []]]]</vip>

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.
{|cellpadding="50" cellspacing="0" border="1"
|+'''Table 1: Heads and Tails of Lists'''
! List
! Head
! Tail
|-
| ['a', 'b', 'c']
| 'a'
| ['b', 'c']
|-
| ['a']
| 'a'
| []
|-
| []
| does not exist
| does not exist
|-
| [[1, 2, 3], [2, 3, 4], []]
| [1, 2, 3]
| [[2, 3, 4], []]
|}

Table 2 gives several examples of list unification.

{|cellpadding="5" cellspacing="0" border="1"
|+'''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 <nowiki>|</nowiki> Y]
|X=7, Y=[]
|-
|[1, 2, 3, 4]
|[X, Y <nowiki>|</nowiki> Z]
|X=1, Y=2, Z=[3,4]
|-
|[1, 2]
|[3 <nowiki>|</nowiki> 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>implement main

clauses
run() :-
write_a_list([1, 2, 3]).

class predicates
write_a_list : (integer* List).
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 main

goal
console::runUtf8(main::run).</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 <vp>write_a_list</vp> predicate is called from <vp>run</vp> clause:

<vip>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>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>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>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 an empty list, <vp>[]</vp>, is <vp>0</vp>. 
*The length of any other list is the length of its tail plus <vp>1</vp>.

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

<vip>class main

predicates
length_of : (A* List) -> integer Length.

end class

implement main

clauses
length_of([]) = 0.
length_of([_ | T]) = Length :-
TailLength = length_of(T),
Length = TailLength + 1.

end implement main

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

Take a look at the second clause first. Crucially, <vp>[_ | T]</vp> will match any nonempty list, binding <vp>T</vp> 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>Length = main::length_of([1, 2, 3])</vip>

will match the second clause, with <vp>T</vp> = <vp>[2, 3]</vp>. The next step is to compute the length of <vp>T</vp>. When this is done (never mind how), <vp>TailLength</vp> will get the value <vp>2</vp>, and the computer can then add <vp>1</vp> to it and bind <vp>Length</vp> to <vp>3</vp>.

So how is the middle step executed? That step was to find the length of <vp>[2, 3]</vp> by satisfying the goal

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

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

*<vp>[3]</vp> in the goal to <vp>T</vp> in the clause and
*<vp>TailLength</vp> in the goal to <vp>Length</vp> in the clause.

Recall that <vp>TailLength</vp> in the goal will not interfere with <vp>TailLength</vp> 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 <vp>[3]</vp>, which will be <vp>1</vp>, and then add <vp>1</vp> to that to get the length of <vp>[2, 3]</vp>, which will be <vp>2</vp>. So far, so good.

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

This time it's easy. The goal:

<vip>TailLength = main::length_of([])</vip>

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

Confused yet? We hope not. In the following brief illustration we'll summarize the calls. We've used suffixes 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>Length_1 = main::length_of([1, 2, 3]).
TailLength_1 = main::length_of([2, 3]).
TailLength_2 = main::length_of([3]).
TailLength_3 = main::length_of([]).
TailLength_3 = 0.
Length_3 = TailLength_3 + 1 = 1.
Length_2 = Length_3 + 1 = 2.
Length_1 = Length_2 + 1 = 3.</vip>

Notice that the code above can be written more compact without the use of intermediate variables like this:

<vip>
clauses
length_of([]) = 0.
length_of([_ | T]) = length_of(T) + 1.
</vip>

These clauses more or less directly states the original specification:

*The length of an empty list, <vp>[]</vp>, is <vp>0</vp>. 
*The length of any other list is the length of its tail plus <vp>1</vp>.

===Tail Recursion===

You probably noticed that <vp>length_of</vp> 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 <vp>length_of</vp> 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 two arguments.

* The first is the list, which the computer will whittle away on each call until it eventually becomes empty, just as before.
* The second is an counter that starts out as <vp>0</vp> and increments on each call.

When the list is finally empty, you'll return the counter as the list length.

<vip>class main

predicates
length_of : (A* List, integer Counter) -> integer Result.

end class

implement main

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

end implement main

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

This version of the <vp>length_of</vp> 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 main

predicates
add1 : (integer* NumberList) -> integer* IncrList.

end class

implement main

clauses
add1([]) = []. % boundary condition
add1([Head | Tail]) = Result :-
% separate the head from the rest of the list
Head1 = Head + 1, % add 1 to the first element
Tail1 = add1(Tail), % call element with the rest of the list
Result = [Head1 | Tail1]. % Put the new head infront of the new tail

end implement main

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

To paraphrase this in natural language:

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

Runnig the the predicate with <vp>[1, 2, 3, 4]</vp>:

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

Will result in

<code>NewList = [2, 3, 4, 5]</code>

=== Tail Recursion Again ===

Is <vp>add1</vp> 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 <vp>Head</vp> and <vp>Tail</vp>.
*Add <vp>1</vp> to <vp>Head</vp>, giving <vp>Head1</vp>.
*Recursively add 1 to all the elements of <vp>Tail</vp>, giving <vp>Tail1</vp>.
*Combine <vp>Head1</vp> and <vp>Tail1</vp>, 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, <vp>add1</vp> is tail-recursive, because its steps are really the following:

*Bind the head and tail of the original list to <vp>Head</vp> and <vp>Tail</vp>.
*Bind the head and tail of <vp>Result</vp> to <vp>Head1</vp> and <vp>Tail1</vp>. (<vp>Head1</vp> and <vp>Tail1</vp> do not have values yet.)
*Add <vp>1</vp> to <vp>Head</vp>, giving <vp>Head1</vp>.
*Recursively add <vp>1</vp> to all the elements of <vp>Tail</vp>, giving <vp>Tail1</vp>.

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

=== More on Modifying Lists ===

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 main

predicates
discard_negatives : (integer*, integer* [out]).

end class

implement main

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 main

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

For example, the goal

<vip>main::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>clauses
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 program below, 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>main::isMember("john", ["john", "leonard", "eric", "frank"])</vip>

is satisfied.

<vip>class main

predicates
isMember : (A, A*) determ.

end class

implement main

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

end implement main

goal
console::init(),
main::isMember("john", ["john", "leonard", "eric", "frank"]),
!,
stdio::write("Success")
or
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 
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 program works in two ways. Consider its clauses once again:

<vip>clauses
isMember(Name, [Name | _]) :-
!.
isMember(Name, [_ | Tail]) :-
isMember(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; 
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; 
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.

This program uses list comprehension to print the average age of a group of people.

<vip>class main

domains
name = string.
address = string.
age = integer.

predicates
person : (name Name [out], address Address [out], age Age [out]) multi.
sumlist : (age* AgeList, age Age [out], integer Count [out]).

end class

implement main

clauses
sumlist([], 0, 0).
sumlist([H | T], Sum, N) :-
sumlist(T, S1, N1),
Sum = H + S1,
N = 1 + N1.

clauses
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 main

goal
console::init(),
L = [Age || main::person(_, _, Age)],
main::sumlist(L, Sum, N),
Average = Sum / N,
stdio::writef("Average = %.", Average).</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 || main::person(Who, _, 42)]</vip>

The following code will create the list of positive items:

<vip>List = [X || X in [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
llist = l(list); i(integer); c(char); s(string).
% the functors are l, i, c, and s</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 main

domains
llist =
l(list);
i(integer);
c(char);
s(string).

predicates
test : ().

end class

implement main

class predicates
append : (A*, A*, A* [out]).
clauses
append([], L, L).
append([X | L1], L2, [X | L3]) :-
append(L1, L2, L3).

clauses
test() :-
append([s("likes"), l([s("bill"), s("mary")])], [s("bill"), s("sue")], Ans),
stdio::write("FIRST LIST: ", Ans, "\n\n"),
append([l([s("This"), s("is"), s("a"), s("list")]), s("bee")], [c('c')], Ans2),
stdio::write("SECOND LIST: ", Ans2, "\n\n").

end implement main</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>/*******************************************
* Lexer
*******************************************/

class lexer

predicates
tokl : (string Input) -> string* TokenTL.

end class lexer

implement lexer

clauses
tokl(Input) = [Tok | tokl(Rest)] :-
string::fronttoken(Input, Tok, Rest),
!.
tokl(_) = [].

end implement lexer

/*******************************************
* Parser
*******************************************/

class parser

domains
program = statement*.

domains
statement =
if_Then_Else(expression Condition, statement ThenPart, statement ElsePart);
if_Then(expression Condition, statement ThenPart);
while(expression Condition, statement Body);
assign(id Variable, expression Expression).

domains
expression =
plus(expression, expression);
minus(expression, expression);
var(id);
int(integer).

domains
id = string.

predicates
program : (string* TL) -> program ProgramTree determ.

end class

implement parser

clauses
program(TL) = Prog :-
Prog = statement_list(TL, TL0),
[] = TL0.

class predicates
statement_list : (string* TL1, string* TL0 [out]) -> program Program determ.
clauses
statement_list([], []) = [] :-
!.
statement_list(TL1, TL0) = [Statement | Program] :-
Statement = statement(TL1, TL2),
TL2 = [";" | TL3],
Program = statement_list(TL3, TL0).

class predicates
statement : (string* TL1, string* TL0 [out]) -> statement Statement determ.
clauses
statement(["if" | TL1], TL0) = if_then_else(Condition, ThenPart, ElsePart) :-
Condition = expression(TL1, TL2),
TL2 = ["then" | TL3],
ThenPart = statement(TL3, TL4),
TL4 = ["else" | TL5],
!,
ElsePart = statement(TL5, TL6),
TL6 = ["fi" | TL0].

statement(["if" | TL1], TL0) = if_then(Condition, Statement) :-
!,
Condition = expression(TL1, TL2),
TL2 = ["then" | TL3],
Statement = statement(TL3, TL4),
TL4 = ["fi" | TL0].

statement(["do" | TL1], TL0) = while(Condition, Statement) :-
!,
Statement = statement(TL1, TL2),
TL2 = ["while" | TL3],
Condition = expression(TL3, TL0).

statement([ID | TL1], TL0) = assign(Id, Exp) :-
string::isname(ID),
TL1 = ["=" | TL2],
Exp = expression(TL2, TL0).

class predicates
expression : (string* TL1, string* TL0 [out]) -> expression Expression determ.
clauses
expression(TL1, TL0) = Exp :-
PreTerm = term(TL1, TL2),
Exp = termTail(TL2, TL0, PreTerm).

class predicates
termTail : (string* TL1, string* TL0 [out], expression PreExpr) -> expression Expr determ.
clauses
termTail(["+" | TL1], TL0, Exp1) = Exp :-
!,
Exp2 = term(TL1, TL2),
Exp = termTail(TL2, TL0, plus(Exp1, Exp2)).

termTail(["-" | TL1], TL0, Exp1) = Exp :-
!,
Exp2 = term(TL1, TL2),
Exp = termTail(TL2, TL0, minus(Exp1, Exp2)).

termTail(TL, TL, Exp) = Exp.

class predicates
term : (string* TL1, string* TL0 [out]) -> expression Expression determ.
clauses
term([Int | Rest], Rest) = int(I) :-
try
I = toTerm(Int)
catch _ do
fail
end try,
!.

term([Id | Rest], Rest) = var(Id) :-
string::isName(Id).

end implement parser

goal
console::init(),
TokenTL = lexer::tokl("b=2; if b then a=1 else a=2 fi; do a=a-1 while a;"),
if ProgramTree = parser::program(TokenTL) then
foreach Stmt in ProgramTree do
stdio::write(Stmt, "\n")
end foreach
else
stdio::write("Parse error\n")
end if.</vip>

The program will write:

<source lang="text">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))))</source>

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. 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 '''program''' predicate takes a list of tokens call the '''statement_list''' predicate on that list. And then is test that all tokens was used in the parse process.
*The predicate '''statement_list''' takes a list of tokens and tests if the tokens can be divided up into individual statements, each ending with a semicolon.
*The predicate '''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 '''statement_list'''.
*The four clauses of the '''statement''' correspond to the four types of statements the parser understands.
**If the first '''statement''' clause is unable to transform the list of tokens into an ''IF THEN ELSE'' statement, the clause fails and backtracks to the next '''statement''' clause.
**The second clause tries to transform the list of tokens into an ''IF THEN'' statement.
**If that clause fails, the next clause tries to transform the list of tokens into a ''DO WHILE'' statement.
**And if all the first three '''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 '''expression''', '''term''', and '''termTail''' predicates work in simailar ways, by testing if the first terms are expressions and – if so – returning the remainder of the terms and an expression structure back to '''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
[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.

[[ru:Списки и рекурсия]]
[[Category:Data types and handling]]

File:FundamentalVisualPrologBusiness fig6.png

2021-10-08T06:59:32Z

Kasper B H Petersen: Kasper B H Petersen reverted File:FundamentalVisualPrologBusiness fig6.png to an old version

Fundamental Visual Prolog - Business 06

{{Tutorial Image}}

File:FundamentalVisualPrologBusiness fig6.png

2021-10-08T06:57:00Z

Kasper B H Petersen: Kasper B H Petersen uploaded a new version of File:FundamentalVisualPrologBusiness fig6.png

Fundamental Visual Prolog - Business 06

{{Tutorial Image}}

Fundamental Visual Prolog - GUI

2021-10-07T11:38:33Z

Kasper B H Petersen: /* Understanding What we have Done So Far */

{{FundamentalPrologNavbar}}

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.

The source files of the example project used in this tutorial are part of the installable examples (in the IDE: '''Help -> Install Examples...''').

==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 '''Project Kind''' is set to '''GUI application''' in '''MDI mode'''.

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 New Package...

:[[Image:FundamentalVisualPrologGui02.PNG]]

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'''.

:[[Image:FundamentalVisualPrologGui03.PNG]]

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

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

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

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

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

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

This is how finally our dialog would look like:

:[[Image:FundamentalVisualPrologGui24.png]]

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

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

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, right click on the TaskMenu.mnu item as seen below:

:[[Image:FundamentalVisualPrologGui10.png]]

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

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

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

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

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

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

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

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

<source lang="text">Undo;Undo</source>

to

<source lang="text">Query fathers;List of all fathers listed in the database</source>

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 insert the following code:

<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 Open from that menu.

:[[Image:FundamentalVisualPrologGui17.png]]

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

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 entities are seen:

:[[Image:FundamentalVisualPrologGui19.png]]

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

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:

<source lang="text">error c229: Undeclared identifier 'ancestorDialog::tryGetName/1->'</source>

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. 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 lines:

<vip>implement ancestorDialog inherits dialog
open core, vpiDomains</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:Fundamental Visual Prolog Tutorial]]
[[Category:GUI]]

Fundamental Visual Prolog

2021-10-06T14:26:47Z

Kasper B H Petersen: /* Step 5: Execute the Program */

{{FundamentalPrologNavbar}}

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

==Differences between 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 provides 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 indication to the Prolog engine about our intention. For example, in the earlier tutorial the <vp>grandFather</vp> predicate's clause was directly written using the traditional Prolog predicate head and body construction. We did not bother to inform the engine in the code that such a predicate construction is to be expected later.

Similarly, when a compound domain is used in traditional Prolog, we can use it without first warning 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 the code for the clause body of a predicate we first need to declare the existence of such a predicate. Similarly, before using any domains, they need to be declared. The reason such forewarnings are required in Visual Prolog is to ensure that runtime exceptions are converted into compile time errors as far as possible.

By ''"runtime exceptions"'', we mean issues that turn up when a program is run. 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 Prolog compilers and the program would fail there. When you declare the predicates and domains in advance, this 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; often, the particular sequence of events that causes a ''runtime exception'' to happen may be so elusive that the bug may only turn up after several years, or it may manifest itself in some critical or other embarrassing situations!

All this implies that the compiler '''has''' to be given explicit instructions regarding the predicates and domains that exist in the code using appropriate declarations before they 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, think of it as a module or a section of the overall program code.

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

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

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

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

'''open'''

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

'''constants'''

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

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

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

'''domains'''

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

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

'''class facts'''

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

'''class predicates'''

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

'''clauses'''

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

'''goal'''

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

====Goal====

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

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

===File Considerations===

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

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

===Scope Access Issues===

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

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

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

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

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

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

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

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

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

<vip>open class1
...

clauses
pred3:-
...
!.

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

===Object Orientation===

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

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

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

The result of following this tutuorial is available as an example in the Visual Prolog installation, use '''Help -> Install Examples...''' to install the examples. This particular example is then in the folder: '…\_tutorial\familyfamily1', where '…' is the folder in which you installed the examples.

Here we will however create it from scratch.

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

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

<vip>implement main

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 [out], string GrandFather [out]) nondeterm.
clauses
grandFather(Person, GrandFather) :-
parent(Person, Parent),
father(Parent, GrandFather).

class predicates
ancestor : (string Person, string Ancestor [out]) nondeterm.
clauses
ancestor(Person, Ancestor) :-
parent(Person, Ancestor).
ancestor(Person, Ancestor) :-
parent(Person, P1),
ancestor(P1, Ancestor).

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

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

run() :-
stdio::write("\ngrandFather test\n"),
grandFather(X, Y),
stdio::writef("% is the grandfather of %\n", Y, X),
fail.

run() :-
stdio::write("\nancestor of Pam test\n"),
X = "Pam",
ancestor(X, Y),
stdio::writef("% is the ancestor of %\n", Y, X),
fail.

run() :-
stdio::write("End of test\n").

end implement main

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

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

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

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

:[[Image:FundamentalVisualProlog2.png]]

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

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

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

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

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

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

:[[Image:FundamentalVisualProlog5.png]]

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

:[[Image:FundamentalVisualProlog6.png]]

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

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

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

:[[Image:FundamentalVisualProlog7.png]]

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

We now have our first true application complied using Visual Prolog. In order to test the application we've just compiled, you can run the program using the '''Build -> Run''' 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 project root folder.

You cannot create such a file directly in the IDE itself, but you can save an existing files with a new name (using '''File -> Save as ...''') and then edit that file. Give the file the name ''fa.txt''. After you have saved the file you can add it to the project by selecting '''File -> Add...'''. The advantage of adding it to the project is that it will be available for any subsequent debugging, etc.

The contents of the file should 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 Window''' menu command, this is what you'll see:

:[[Image:FundamentalVisualProlog8.png]]

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

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

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

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

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

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

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

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

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

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

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

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

==Conclusion==

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

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

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