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

Language Reference/Terms/Anonymous Predicates

2016-11-08T09:14:37Z

Tbn: /* Background threads */ minor typos

An anonymous predicate is an expression that evaluates to a predicate value. The predicate value can be bound to a variable, passed as arguments or returned as result, but the value does not have a name in any class, interface or implementation.

Anonymous predicates have the ability to capture values from the context in which the expression occurs, this is a rather powerful ability that can be used to avoid rather excessive amount of strange/unpleasant code.

==== Syntax ====

Anonymous predicates are terms:

<vipbnf><Term> : one of
...
<AnonymousPredicate>
...</vipbnf>

An anonymous predicate is a nameless clause in curly brackets. Certain parts are optional, giving these forms:

<vipbnf><AnonymousPredicate> : one of
{ ( <Arg>-comma-sep-list ) = <Term> }
{ ( <Arg>-comma-sep-list ) = <Term> :- <Term> }
{ ( <Arg>-comma-sep-list ) :- <Term> }
{ = <Term> }
{ = <Term> :- <Term> }
{ :- <Term> }</vipbnf>

Leaving out the argument list means "the required number of arguments" and can be used whenever the arguments are not used.

==== Semantics ====

An anonymous predicate expression evaluates to a predicate value.
Consider this code:

<vip>clauses
run() :-
Inc = { (X) = X+1 },
A = Inc(4),
B = Inc(23),
stdio::writef("A = %, B = %", A, B).</vip>

Inc becomes an increment predicate, so the program will write:

<source lang="text">A = 5, B = 24</source>

The code in this example corresponds to this code:

<vip>clauses
run() :-
Inc = inc,
A = Inc(4),
B = Inc(23),
stdio::writef("A = %, B = %", A, B).

class predicates
inc : (integer X) -> integer R.
clauses
inc(X) = X+1.</vip>

Where the clause <vp>(X) = X+1</vp> can be found in the last line. I.e. this time in a named predicate.

Variables that are bound outside (i.e. before the occurrence of) an anonymous predicate can be used inside the anonymous predicate. The value of variable will be captured by the anonymous predicate.

Variables that are bound in an anonymous predicate are local variables in the anonymous predicate.

===== Capturing context =====

An anonymous predicate can capture context, which means that it can refer to things that are defined in its context, especially facts and variables from the clause.

===== Capturing Variables =====

Anonymous predicate occurs in a clause, and this clause may contain variables. Those variables that are bound before the anonymous predicate is met can be used inside the anonymous predicate.
This code illustrates how a variable is captured:

<vip>domains
pred = (integer) -> integer.

class predicates
createAdder : (integer A) -> pred Adder.
clauses
createAdder(A) = { (X) = X+A }.

clauses
run() :-
Add17 = createAdder(17),
A = Add17(4),
B = Add17(20),
stdio::writef("A = %, B = %", A, B).</vip>

We call <vp>createAdder</vp> with <vp>17</vp> as argument. So in the <vp>createAdder</vp> clause <vp>A</vp> is <vp>17</vp>, and therefore the result is <vp>{ (X) = X+17 }</vp>. We say that the anonymous predicate has captured the variable <vp>A</vp>.

Since <vp>Add17</vp> is a predicate that adds <vp>17</vp> to its argument, the output of the code will be:

<source lang="text">A = 21, B = 37</source>

===== Capturing ellipsis (...) =====

An anonymous predicate can capture the ellipsis variable (i.e. ...):

<vip>clauses
ppp(...) :-
W = { () :- stdio::write(...) },
qqq(W).</vip>

<vp>W</vp> captures the ellipsis variable. <vp>qqq</vp> receives a zero-arity predicate, when this predicate is invoked the captured ellipsis variable will be written to the standard output device.

===== Capturing Facts =====

An anonymous predicate can access facts. If it is created by a class predicate it can access class facts. If it is created by an object predicate it can access both object and class facts.
Consider this code that captures a class fact:

<vip>class facts
count : integer := 0.
clauses
seq() = { () = count :- count := count+1 }.
clauses
run() :-
A = seq(),
B = seq(),
stdio::writef("A1 = %, ", A()),
stdio::writef("B1 = %, ", B()),
stdio::writef("A2 = %, ", A()),
stdio::writef("B2 = %", B()).</vip>

Both <vp>A</vp> and <vp>B</vp> increment the class fact count, so the result is

<source lang="text">A1 = 1, B1 = 2, A2 = 3, B2 = 4</source>

In object predicates we can capture object facts. So assuming that <vp>seq</vp> is an object predicate in <vp>myClass</vp>, this code illustrates the capture of an object fact:

<vip>facts
count : integer := 0.
clauses
seq() = { () = count :- count := count+1 }.
clauses
run() :-
A = myClass::new():seq(),
B = myClass::new():seq(),
stdio::writef("A1 = %, ", A()),
stdio::writef("B1 = %, ", B()),
stdio::writef("A2 = %, ", A()),
stdio::writef("B2 = %", B()).</vip>

In this case <vp>A</vp> and <vp>B</vp> comes from two different objects, which each have a count fact, so the output will be:

<source lang="text">A1 = 1, B1 = 1, A2 = 2, B2 = 2</source>

Technically, the class version actually doesn't capture anything, it merely have access to the fact. Likewise, the object version doesn't actually capture the fact, instead it captures This and through This it obtains access to the object facts.

===== Capturing This =====

As described above it is possible to capture <vp>This</vp> and thereby gaining access to objects facts. The same mechanism gives access to calling object predicates.

<vip>clauses
seq() = { () = count :- inc() }.

clauses
inc() :- count := count+1.</vip>
<vp>This</vp> can also be used directly:
<vip>clauses
ppp() = { () = aaa::rrr(This) }.</vip>

===== Nesting =====

Anonymous predicates can be nested:

<vip>clauses
run() :-
P = { (A) = { (B) = A+B } },
Q = P(3300),
R = P(2200),
stdio::writef("Q(11) = %, ", Q(11)),
stdio::writef("R(11) = %", R(11)).</vip>

To obtain <vp>Q</vp> we call <vp>P</vp> with <vp>3300</vp>, so <vp>A</vp> is <vp>3300</vp> and <vp>Q</vp> therefore becomes <vp>{ (B) = 3300+B } }</vp>, likewise R becomes <vp>{ (B) = 2200+B } }</vp>. So, the output is:

<source lang="text">Q(11) = 3311, R(11) = 2211</source>

==== Syntactic Sugar ====

If you don't need the arguments they can be skipped.
So this code-fragment:

<vip>P = { (_) :- succeed },
Q = { (_, _) = 0 },
R = { (_, _, _) = _ :- fail }
Can be shortened down to this:
P = { :- succeed },
Q = { = 0 },
R = { = _ :- fail }</vip>

Notice that the arguments are completely skipped. If you write <vp>()</vp> it means zero arguments, whereas skipping the arguments means "a suitable amount" of arguments.

==== Examples of practical usage ====

This section shows some cases where anonymous predicates are very handy. The examples assume that the PFC scopes core, std, stdio, list and string are open.

===== Dummy predicates =====

Anonymous predicates are good for creating dummy predicate values:

<vip>ppp( { = true } ), % don't filter (boolean)
qqq( { :- succeed } ), % don't filter (determ)
rrr( { = 17 } ), % all rows must have height 17</vip>

===== Adaptation =====

In cases where you need a predicate and have one that is almost suitable, you can make the adaptation using an anonymous predicate.

===== Index adaptation =====

Consider the predicate write3:

<vip>class predicates
write3 : (function{integer, string} Indexer).
clauses
write3(Indexer) :-
foreach I = std::fromTo(0,2) do
write(Indexer(I), "\n")
end foreach.</vip>

Indexer implements an "array" of strings, <vp>write3</vp> will write the three strings found at the indexes <vp>0</vp>, <vp>1</vp> and <vp>2</vp>. So <vp>write3</vp> assumes that the "array" index is zero-based.
However, the "array" we have uses a one-based index:

<vip>class predicates
myArray : (integer N) -> string Value.
clauses
myArray(1) = "First" :- !.
myArray(2) = "Second" :- !.
myArray(3) = "Third" :- !.
myArray(_) = _ :-
raiseError().</vip>

But using an anonymous predicate we can easily adapt the one-based array to the zero-based usage:

<vip>% myArray is 0-based, write3 requires 1-based
Arr = { (N) = myArray(N+1) },
write3(Arr)</vip>

So we get the expected output:

<source lang="text">First
Second
Third</source>

===== Parameter adaptation =====

In this code <vp>listChildren</vp> will call a <vp>ChildWriter</vp> predicate for each "<vp>C</vp> is the child of <vp>P</vp>"-pair:

<vip>class predicates
listChildren :
(predicate{string,string} ChildWriter).
clauses
listChildren(CW) :-
CW("Son1", "Father"),
CW("Son2", "Father").</vip>

We will however prefer to list the "<vp>P</vp> is the parent of <vp>C</vp>" using the predicate <vp>wParent</vp>:

<vip>class predicates
wParent : (string Parent, string Child).
clauses
wParent(P, C) :-
writef("% is the parent of %\n", P, C).</vip>

<vp>wParent</vp> takes the arguments in the opposite order, but we can easily adapt using an anonymous predicate:

<vip>Swap = { (A,B) :- wParent(B,A) },
listChildren(Swap)</vip>

And then the out becomes the expected:

<source lang="text">Father is the parent of Son1
Father is the parent of Son2</source>

We can also throw away arguments, for example when calling this predicate that only needs a <vp>Child</vp>:

<vip>class predicates
wKnowParent : (string Child).
clauses
wKnowParent(C) :-
writef("We know a parent of %\n", C).</vip>

The adaptation looks like this:

<vip>Fewer = { (C,P) :- wKnowParent(C) },
listChildren(Fewer)</vip>

The output will be:

<source lang="text">We know a parent of Son1
We know a parent of Son2</source>

We can also supply dummy arguments:

<vip>More = { (_,P) :- addChildren(P, 1) }
listChildren(More)</vip>

Here <vp>addChildren</vp> will "add a count of children to <vp>P</vp>". Since each invocation corresponds to one child we will call <vp>addChild</vp> supplying <vp>1</vp> as a "dummy" argument. The More is thus an adaptor that both throws away an argument and supplies a dummy argument.

===== Filters =====

Assume this predicate:

<vip>class predicates
writeFiltered :
(string L, predicate_dt{integer} Filter).
clauses
writeFiltered(Label, Filter) :-
List = [1,2,3,4,5,6,7,8,9],
FilteredList = filter(List, Filter),
writef("%\t%\n", Label, FilteredList).</vip>

Filter is used to filter the list <vp>[1,2,3,4,5,6,7,8,9]</vp>; the filtered list and the Label are written to the standard output.

First we use the allow-all filter:

<vip>All = { :- succeed },
writeFiltered("All", All)</vip>

This filter simply succeeds for any element, so the output is the entire list:

<source lang="text">All [1,2,3,4,5,6,7,8,9]</source>

It is just as easy to create a filter that fails for all elements and thus allow-none:

<vip>None = { :- fail },
writeFiltered("None", None)</vip>

The output from this is the empty list:

<source lang="text">None []</source>

We can also create filters for elements greater than <vp>3</vp> and elements dividable by <vp>3</vp>:

<vip>GreaterThan3 = { (X) :- X > 3 },
writeFiltered("> 3", GreaterThan3),
Rem3 = { (X) :- 0 = X rem 3 },
writeFiltered("Rem3", Rem3)</vip>

The output from this is:

<source lang="text">> 3 [4,5,6,7,8,9]
Rem3 [3,6,9]</source>

===== Sorting =====

The list package has a sort predicate. But sometimes the default order is not what you need. Therefore the list package also has a predicate sortBy, which sorts the elements using a programmer defined compare operation.
Let us first consider string sorting, using this predicate:

<vip>class predicates
writeStringsSorted :
(string Label, comparator{string} Comp).
clauses
writeStringsSorted(Label, C) :-
List = ["John Wayne", "Uma Thurman",
"Harrison Ford", "Nicolas Cage",
"Elizabeth Taylor", "Cary Grant",
"Jerry Lewis", "Robert De Niro"],
Sorted = sortBy(C, List),
write(Label, "\n"),
foreach S = list::getMember_nd(Sorted) do
writef(" %\n", S)
end foreach.</vip>

We can call the predicate with the "normal" comparator, and using an anonymous predicate we can easily sort it descending as well:

<vip>Normal = compare,
writeStringsSorted("Normal", Normal),
Descending = { (A,B) = compare(B,A) },
writeStringsSorted("Descending", Descending)</vip>

The output looks like this:

<source lang="text">Normal
Cary Grant
Elizabeth Taylor
Harrison Ford
Jerry Lewis
John Wayne
Nicolas Cage
Robert De Niro
Uma Thurman
Descending
Uma Thurman
Robert De Niro
Nicolas Cage
John Wayne
Jerry Lewis
Harrison Ford
Elizabeth Taylor
Cary Grant</source>

Let us also sort some more complex elements. Here a person has a first name and a last name, using this domain:

<vip>domains
person = p(string First, string Last).</vip>
For the demonstration we will use this test predicate:
<vip>class predicates
writePersonsSorted :
(string Label, comparator{person} Comparator).
clauses
writePersonsSorted(Label, C) :-
List = [p("John","Wayne"),
p("Uma","Thurman"),
p("Harrison","Ford"),
p("Nicolas","Cage"),
p("Elizabeth","Taylor"),
p("Cary","Grant"),
p("Jerry","Lewis"),
p("Robert","De Niro")],
Sorted = sortBy(C, List),
write(Label, "\n"),
foreach p(F,L) = list::getMember_nd(Sorted) do
writef(" % %\n", F, L)
end foreach.</vip>

Again we can sort using the normal and a descending comparator:

<vip>Normal = compare,
writePersonsSorted("Normal", Normal),
Descending = { (A,B) = compare(B,A) },
writePersonsSorted("Descending", Descending)</vip>

Since the compare predicate uses left-to-right lexicographic order on the <vp>p</vp>-functor, the result is the same as before:

<source lang="text">Normal
Cary Grant
Elizabeth Taylor
Harrison Ford
Jerry Lewis
John Wayne
Nicolas Cage
Robert De Niro
Uma Thurman
Descending
Uma Thurman
Robert De Niro
Nicolas Cage
John Wayne
Jerry Lewis
Harrison Ford
Elizabeth Taylor
Cary Grant</source>

But with the more complex domain we can create a comparator that will sort on last name:

<vip>LN = { (p(_,L1), p(_, L2)) = compare(L1,L2) },
writePersonsSorted("LastName", LN)</vip>

The result is what we expect:

<source lang="text">LastName
Nicolas Cage
Robert De Niro
Harrison Ford
Cary Grant
Jerry Lewis
Elizabeth Taylor
Uma Thurman
John Wayne</source>

===== Capturing context =====

As mentioned a very powerful feature of anonymous predicates is the ability to capture context. The examples in this section show some ways you can use this.

===== Background threads =====

The routine for starting a thread takes a null-ary predicate and runs it in the new thread. But you nearly always need to pass some input data to the job in the new thread.
This is possible in several ways, but the absolutely simplest way is to use anonymous predicates.
The project <vp>bgDemo</vp> from the Visual Prolog example collection (that can be installed from the IDE) use this method.
The project has a form that can start a background job and display status information from the job in a <vp>jobControl</vp> that is added to the form.
A background job is a predicate that will receive a <vp>jobLog</vp>, which it can use to report status and completion degree:

<vip>domains
job = (jobLog Log).</vip>
A jobLog looks like this:
<vip>interface jobLog

properties
completion : real (i).

properties
status : string (i).

end interface jobLog</vip>

The job can report completion degree by setting the completion property (range <vp>0</vp> to <vp>1</vp>). Likewise, the status property can be used to reflect the current status of the job.

The status and completion will be shown in the form together with a job name.
A job is started by calling the form's <vp>addJob</vp> predicate:

<vip>clauses
addJob(JobName, Job) :-
JobCtrl = jobControl::new(This),
JobCtrl:name := JobName,
JobCtrl:show(),
assert(jobCtrl_fact(JobCtrl)),
arrange(),
JobLog = jobLog::new(JobCtrl),
Action = { :- Job(JobLog) },
_ = thread::start(Action).</vip>

In this context it is the last three lines that are interesting. <vp>thread::start</vp> takes a null-ary predicate as argument, but a job is a predicate that takes a <vp>jobLog</vp> as argument. Therefore we create an anonymous predicate <vp>Action</vp>, which takes no arguments but invokes <vp>Job</vp> on the <vp>JobLog</vp>. The anonymous predicate has captured both <vp>Job</vp> and <vp>JobLog</vp> from the context, and subsequently both these values are transferred to the new thread even though this thread only receives a null-ary predicate.
The jobs in the <vp>bgDemo</vp> project are merely dummy jobs that only manipulate their <vp>jobLog</vp>. One of them looks like this:

<vip>clauses
job(Log, From, To) :-
Log:status := "Step 1",
foreach N1 = std::fromTo(From, To) do
Log:completion :=
(N1-From) / (To-From) / 2,
programControl::sleep(3)
end foreach,
Log:status := "Step 2",
foreach N2 = std::fromTo(From, To) do
Log:completion :=
(N2-From) / (To-From) / 2 + 0.5,
programControl::sleep(3)
end foreach,
Log:status := "finished".</vip>

It has two loops which run from <vp>From</vp> to <vp>To</vp> and calculates the completion and sets it on the <vp>Log</vp>. It also sets the status text before, between and after the loops.
You may notice that the job does not have the proper job type, because a proper job only has one argument (the <vp>jobLog</vp>), this job has three arguments.
Again it is anonymous predicates that help us. The code that adds the jobs to the form looks like this:

<vip>predicates
onFileNew : window::menuItemListener.
clauses
onFileNew(_Source, _MenuTag) :-
JF = jobForm::display(This),
Job11 = {(L) :- job1::job(L, 1, 1000)},
Job12 = {(L) :- job1::job(L, 200, 600)},
Job13 = {(L) :- job1::job(L, 1200, 3000)},
Job14 = {(L) :- job1::job(L, 1, 1000)},
JF:addJob("job1.1", Job11),
JF:addJob("job1.2", Job12),
JF:addJob("job1.3", Job13),
JF:addJob("job1.4", Job14),
...</vip>

In a more realistic program, it is most likely that <vp>From</vp> and <vp>To</vp> would not be constants, but rather parameters passed from some outer place. In that case these anonymous predicates would also capture variables from the context.
The <vp>jobLog</vp> in the <vp>bgDemo</vp> illustrates one more usage of anonymous predicates. The <vp>jobLog</vp> pass the completion and the status information to a <vp>jobControl</vp>. The <vp>jobControl</vp> is a GUI control on the <vp>jobForm</vp> capable of doing a suitable rendering of the information. This however gives a synchronization problem, because GUI controls are not thread safe and here we want to update some controls from a background thread. This can lead to conflicts, because it is the main thread that draws the controls.
The solution is to make transfer the the update of the control to the GUI thread. We do this by posting actions to the control.
The implementation of the status update looks like this:

<vip>clauses
status(Status) :-
Action = { :- jobCtrl:status := Status },
jobCtrl:postAction(Action).</vip>

<vp>Action</vp> is a null-ary predicate that will set the status in the <vp>jobCtrl</vp>. We post this action to the <vp>jobCtrl</vp>. When the <vp>jobCtrl</vp> receives the action it invokes it and is thus updated. This way, the actual update of the control will be performed by the GUI thread.
This anonymous predicate not only captures the <vp>Status</vp> variable it also captures the <vp>jobCtrl</vp> fact.

===== Asynchronous callbacks =====

Assume that we send commands to a remote service. The command execution is asynchronous, so when we execute a command we also give a callback action which will be invoked when the execution of the command is finished. To execute a command we must call this predicate:

<vip>predicates
executeCommand :
(command Cmd, predicate{} OnDone).</vip>

Based on this predicate we want to create a similar predicate that can execute a list of commands. A certain command should be executed when the previous command completes.
We will also make our list executor asynchronous, so we supply an action that will be invoked when the entire script of commands are finished.
Our script executer will have the form:

<vip>predicates
executeScript :
(command* Script, predicate{} OnDone).</vip>

If the script is empty we simply invoke the <vp>OnDone</vp> action.
If the script has a command <vp>H</vp> and a rest script <vp>T</vp>, we must first execute <vp>H</vp>, and when it is finished we must execute the rest of the script <vp>T</vp>. So the <vp>OnDone</vp> action we supply when executing <vp>H</vp> must execute <vp>T</vp>.
All in all, the implementation can look like this:

<vip>clauses
executeScript([], OnDone) :-
OnDone().
executeScript([H|T], OnDone) :-
DoneH = { :- executeScript(T, OnDone) },
executeCommand(H, DoneH).</vip>

We have used an anonymous predicate to perform the execution of the rest of the script. This anonymous predicate captures <vp>T</vp> and <vp>OnDone</vp>.
<noinclude>{{LanguageReferenceSubarticle|Terms/Anonymous Predicates}}</noinclude>

Language Reference/Attributes

2016-11-07T09:34:20Z

Tbn: /* retired */ minor typos

{{languageReferenceNavbar|Attributes}}

Various definitions and declarations can be annotated with attributes. This section describes the general syntax of attributes and where they can be placed. It also describes the meaning of the specific attributes.

=== Syntax ===

<vipbnf><Attributes> :
[ <Attribute>-comma-sep-list ]</vipbnf>

<vipbnf><Attribute> : one of
<LowerCaseIdentifier>
<LowerCaseIdentifier> ( <Literal>-comma-sep-list )</vipbnf>

where the literals must either be numbers or string literals.

=== Insertion Points ===

The attributes of interfaces, classes and implementations are right after the scope qualifications.

<vipbnf><InterfaceDeclaration> :
interface <IinterfaceName>
<ScopeQualifications>
<Attributes>-opt
<Sections>
end interface <IinterfaceName>-opt</vipbnf>

<vipbnf><ClassDeclaration> :
class <ClassName> <ConstructionType>-opt
<ScopeQualifications>
<Attributes>-opt
<Sections>
end class <ClassName>-opt</vipbnf>

<vipbnf><ClassImplementation> :
implement <ClassName>
<ScopeQualifications>
<Attributes>-opt
<Sections>
end implement <ClassName>-opt</vipbnf>

The attributes of constants, domains, predicates, properties and facts are at the end (i.e. right before the terminating dot).

<vipbnf><ConstantDefinition>: one of
<ConstantName> = <ConstantValue> <Attributes>-opt
<ConstantName> : <TypeName> = <ConstantValue> <Attributes>-opt</vipbnf>

<vipbnf><DomainDefinition>:
<DomainName> <FormalTypeParameterList>-opt = <TypeExpression> <Attributes>-opt</vipbnf>

<vipbnf><PredicateDeclaration> :
<PredicateName> : <PredicateDomain> <LinkName>-opt <Attributes>-opt
<PredicateName> : <PredicateDomainName> <LinkName>-opt <Attributes>-opt</vipbnf>

<vipbnf><PropertyDeclaration> :
<PropertyName> : <PropertyType> <FlowPattern>-list-opt <Attributes>-opt</vipbnf>

<vipbnf><FactDeclaration> :
<FactVariableDeclaration> <Attributes>-opt
<FactFunctorDeclaration> <Attributes>-opt</vipbnf>

The attributes of formal arguments are at the end.

<vipbnf><FormalArgument> :
<TypeExpression> <ArgumentName>-opt <Attributes>-opt</vipbnf>

=== Specific Attributes ===

==== byVal ====

An argument is transferred directly on the stack rather than using a pointer. Valid for formal predicate arguments provided the <vp>language</vp> is <vp>stdcall</vp>, <vp>apicall</vp> or <vp>c</vp>.

{{Example|
<vip>predicates
externalP : (point Point [byVal]) language apicall.</vip>
}}

==== deprecated ====

The declared entity is deprecated. The string literal describes how to migrate from it. The entity still exists, but usage will cause a warning.
The entity will not exist in future versions of Visual Prolog. Valid for member declarations and scopes.

{{Example|
<vip>predicates
oldFashioned : (string Arg) [deprecated("Use newFashion instead")].</vip>
}}

==== formatString ====

The argument is a {{lang2|Domains|Format Strings|format string}} for a subsequent ellipsis argument (i.e. <vp>...</vp>). Valid for one string argument of a predicate with an ellipsis argument. The use of formatString will make the compiler check the validity of actual arguments with respect to actual format strings (where possible).

{{Example|
<vip>predicates
writef : (string Format [formatString], ...).</vip>
}}

==== in ====

The argument is an input argument. Valid for a formal predicate argument.

{{Example|
<vip>predicates
pred : (string InputArg [in]).</vip>
}}

==== inline ====

<vp>inline</vp> alters the memory layout of a struct (i.e. a single alternative functor domain with an align qualification). The purpose of the attribute is to ease interfacing to foreign languages and should normally not be used for pure Visual Prolog.

<vp>inline</vp> can be used in three cases:

* inlining a struct rather than having a pointer to the struct
* inlining a fixed size string
* inlining a fixed number of bytes

When using <vp>inline</vp> on struct field in another struct its data will be inlined instead of having a pointer to the struct

{{Example|
<vip>domains
point =p(integer X, integer Y).

domains
rectangle =
r(
point UpperLeft [inline],
point LowerRight [inline]
).</vip>
Since <vp>UpperLeft</vp> and <vp>LowerRight</vp> are inlined the struct have the same memory layout as this one:
<vip>domains
rectangle2 =
r2(
integer UpperLeft_X,
integer UpperLeft_Y,
integer LowerRight_X,
integer LowerRight_Y
).</vip>
}}

When using <vp>inline(<size>)</vp> on a <vp>string</vp> or a <vp>string8</vp> field in a struct, the struct will contain a fixed size string with <vp><size></vp> characters (i.e. <vp>char</vp> or <vp>char8</vp>, respectively). The strings will be zero terminated if they are shorter than <vp><size></vp>, but not if they have <vp><size></vp> characters.

{{Example|
<vip>domains
device =
device(
integer Id,
string DeviceName [inline(12)]
).</vip>
<vp>DeviceName</vp> is an inlined Unicode string of length 12.
The struct have the same layout as:
<vip>domains
device =
device(
integer Id,
char DeviceName_01,
char DeviceName_02,
char DeviceName_03,
char DeviceName_04,
char DeviceName_05,
char DeviceName_06,
char DeviceName_07,
char DeviceName_08,
char DeviceName_09,
char DeviceName_10,
char DeviceName_11,
char DeviceName_12
).</vip>
}}

When using <vp>inline(<size>)</vp> on the <vp>pointer</vp> type the struct will contain <vp><size></vp> bytes, and the pointer will become a pointer to that field:

{{Example|
<vip>domains
mark =
mark(
integer Position,
pointer Data [8]
).</vip>
<vp>Data</vp> is pointer to 8 inlined bytes
The struct have the same layout as:
<vip>domains
mark2 =
mark2(
integer Position,
byte Data_1,
byte Data_2,
byte Data_3,
byte Data_4,
byte Data_5,
byte Data_6,
byte Data_7,
byte Data_8
).</vip>
And <vp>Data</vp> will point to <vp>Data_1</vp>.
}}

==== noDefaultConstructor ====

Used for a class to indicate that it should not have an implicit default constructor, and can thus be used to a class that does not have any public constructors at all. Valid for an object creating class declaration.

{{Example|
<vip>class classWithoutPublicConstructors : myInterface
open core
[noDefaultConstructor]
...
end class classWithoutPublicConstructors</vip>
}}

==== out ====

The argument is an output argument. Valid for a formal predicate argument.

{{Example|
<vip>predicates
pred : (string OutputArg [out]).</vip>
}}

==== programPoint ====

Used for a predicate or constructor declaration to indicate that it recieves an extra input argument which describes the place in a program (program point) where this predicate was called. This additional argument has programPoint type which is declared in the PFC core class like:

<vip>domains
programPoint = programPoint(hScopeDescriptor ClassDescriptor, string PredicateName, sourceCursor Cursor).
</vip>

The clause name of such predicate or constructor should have suffix "_explicit". Valid for a predicate or constructor declaration.

{{Example|
<vip>predicates
pred : (string String) [programPoint].
clauses
pred_explicit(ProgramPoint, String) :-
...
</vip>
}}

The <vp>programPoint</vp> attribute is described in more details in the description of [[Language Reference/Predicates#programPoint|Predicates]], and it is a vital part of the exception system, see [[Exception Handling]].

==== retired ====

The declared entity is retired. The string literal describes how to migrate from it. The entity does not exist anymore.

{{Example|
<vip>predicates
veryOldFashioned : (string Arg) [retired("Use newFashion instead")].</vip>
}}

==== sealed ====

Used for an interface to indicate that it cannot be supported by any other interface. This allows to create more efficient codes, because the compiler provides some optimization when using the objects of such type. Valid for an object creating class declaration as a construction interface.

{{Example|
<vip>interface myInterface
[sealed]
...
end interface myInterface

class myClass : myInterface
...
end class myClass</vip>
}}

==== union ====

Used for creating functor domains with several alternatives but no real functors. This should only be used to mimic C/C++ union structs in low-level interfacing. Valid for functor domain with several alternatives and alignment.

{{Example|
<vip>domains
u64var = align 4
u64(unsigned64 Value64);
u64_struct(unsigned Low32, unsigned High32)
[union].</vip>
}}

==== used ====

An unused local member can be marked <vp>used</vp> to prevent the compiler to issue a warning and remove the corresponding code. Valid for members.

{{Example|
<vip>predicates
seeminglyUnused : () [used].</vip>
}}

==== default ====

{{Template:NonReleased}}

It is problematic to update functor domains, if terms have been persisted in serialized form. Because new programs cannot deal with old serializations.

The two attributes <vp>default/1</vp> and <vp>retiredFunctor/1</vp> can help dealing with this problem.

The last arguments of a functor can have default values:

<vip>domains
ppp =
fct(
integer A,
real B,
ddd C,
integer* New [default([])],
real New2 [default(0)]
).</vip>

The default attribute does not change anything within the program; it only affects the deserialization. If during deserialization we meet the closing parenthesis too soon we supply default values for the remaining arguments.

'''Notice''' that this will only work for '''text''' deserialization.

See also [[Functor Domain Versioning]].

==== retiredFunctor ====

{{Template:NonReleased}}

Functor alternatives can be retired.

<vip>domains
ppp =
fct(integer A, real B, ddd C) [retiredFunctor(aaa::fct_ppp)];
fct2(integer A, ddd C, integer* New).</vip>

<vp>aaa::fct_ppp</vp> must be a predicate with this type (it can be an anonymous predicate):

<vip>predicates
fct_ppp : (integer A, real B, ddd C) -> ppp NewValue.</vip>

I.e. it takes the arguments of the old functor and returns a value in the functor domain.

In the program fct is does not exist at all, it is retired. But in the deserialization fct terms can still be handled: The arguments are parsed according to the types, and then the value is created by invoking <vp>aaa::fct_ppp</vp>.

This method will also work for binary serializations, provided:

* The old domain had more than one alternative (so there are functor numbers in the serialization)
* New alternatives are added last (to retain functor numbers)

It is however not recommend using binary serialization for inter-session persistence.

See also [[Functor Domain Versioning]].

Language Reference/Attributes

2016-11-07T09:32:15Z

Tbn: /* deprecated */ minor typos.

{{languageReferenceNavbar|Attributes}}

Various definitions and declarations can be annotated with attributes. This section describes the general syntax of attributes and where they can be placed. It also describes the meaning of the specific attributes.

=== Syntax ===

<vipbnf><Attributes> :
[ <Attribute>-comma-sep-list ]</vipbnf>

<vipbnf><Attribute> : one of
<LowerCaseIdentifier>
<LowerCaseIdentifier> ( <Literal>-comma-sep-list )</vipbnf>

where the literals must either be numbers or string literals.

=== Insertion Points ===

The attributes of interfaces, classes and implementations are right after the scope qualifications.

<vipbnf><InterfaceDeclaration> :
interface <IinterfaceName>
<ScopeQualifications>
<Attributes>-opt
<Sections>
end interface <IinterfaceName>-opt</vipbnf>

<vipbnf><ClassDeclaration> :
class <ClassName> <ConstructionType>-opt
<ScopeQualifications>
<Attributes>-opt
<Sections>
end class <ClassName>-opt</vipbnf>

<vipbnf><ClassImplementation> :
implement <ClassName>
<ScopeQualifications>
<Attributes>-opt
<Sections>
end implement <ClassName>-opt</vipbnf>

The attributes of constants, domains, predicates, properties and facts are at the end (i.e. right before the terminating dot).

<vipbnf><ConstantDefinition>: one of
<ConstantName> = <ConstantValue> <Attributes>-opt
<ConstantName> : <TypeName> = <ConstantValue> <Attributes>-opt</vipbnf>

<vipbnf><DomainDefinition>:
<DomainName> <FormalTypeParameterList>-opt = <TypeExpression> <Attributes>-opt</vipbnf>

<vipbnf><PredicateDeclaration> :
<PredicateName> : <PredicateDomain> <LinkName>-opt <Attributes>-opt
<PredicateName> : <PredicateDomainName> <LinkName>-opt <Attributes>-opt</vipbnf>

<vipbnf><PropertyDeclaration> :
<PropertyName> : <PropertyType> <FlowPattern>-list-opt <Attributes>-opt</vipbnf>

<vipbnf><FactDeclaration> :
<FactVariableDeclaration> <Attributes>-opt
<FactFunctorDeclaration> <Attributes>-opt</vipbnf>

The attributes of formal arguments are at the end.

<vipbnf><FormalArgument> :
<TypeExpression> <ArgumentName>-opt <Attributes>-opt</vipbnf>

=== Specific Attributes ===

==== byVal ====

An argument is transferred directly on the stack rather than using a pointer. Valid for formal predicate arguments provided the <vp>language</vp> is <vp>stdcall</vp>, <vp>apicall</vp> or <vp>c</vp>.

{{Example|
<vip>predicates
externalP : (point Point [byVal]) language apicall.</vip>
}}

==== deprecated ====

The declared entity is deprecated. The string literal describes how to migrate from it. The entity still exists, but usage will cause a warning.
The entity will not exist in future versions of Visual Prolog. Valid for member declarations and scopes.

{{Example|
<vip>predicates
oldFashioned : (string Arg) [deprecated("Use newFashion instead")].</vip>
}}

==== formatString ====

The argument is a {{lang2|Domains|Format Strings|format string}} for a subsequent ellipsis argument (i.e. <vp>...</vp>). Valid for one string argument of a predicate with an ellipsis argument. The use of formatString will make the compiler check the validity of actual arguments with respect to actual format strings (where possible).

{{Example|
<vip>predicates
writef : (string Format [formatString], ...).</vip>
}}

==== in ====

The argument is an input argument. Valid for a formal predicate argument.

{{Example|
<vip>predicates
pred : (string InputArg [in]).</vip>
}}

==== inline ====

<vp>inline</vp> alters the memory layout of a struct (i.e. a single alternative functor domain with an align qualification). The purpose of the attribute is to ease interfacing to foreign languages and should normally not be used for pure Visual Prolog.

<vp>inline</vp> can be used in three cases:

* inlining a struct rather than having a pointer to the struct
* inlining a fixed size string
* inlining a fixed number of bytes

When using <vp>inline</vp> on struct field in another struct its data will be inlined instead of having a pointer to the struct

{{Example|
<vip>domains
point =p(integer X, integer Y).

domains
rectangle =
r(
point UpperLeft [inline],
point LowerRight [inline]
).</vip>
Since <vp>UpperLeft</vp> and <vp>LowerRight</vp> are inlined the struct have the same memory layout as this one:
<vip>domains
rectangle2 =
r2(
integer UpperLeft_X,
integer UpperLeft_Y,
integer LowerRight_X,
integer LowerRight_Y
).</vip>
}}

When using <vp>inline(<size>)</vp> on a <vp>string</vp> or a <vp>string8</vp> field in a struct, the struct will contain a fixed size string with <vp><size></vp> characters (i.e. <vp>char</vp> or <vp>char8</vp>, respectively). The strings will be zero terminated if they are shorter than <vp><size></vp>, but not if they have <vp><size></vp> characters.

{{Example|
<vip>domains
device =
device(
integer Id,
string DeviceName [inline(12)]
).</vip>
<vp>DeviceName</vp> is an inlined Unicode string of length 12.
The struct have the same layout as:
<vip>domains
device =
device(
integer Id,
char DeviceName_01,
char DeviceName_02,
char DeviceName_03,
char DeviceName_04,
char DeviceName_05,
char DeviceName_06,
char DeviceName_07,
char DeviceName_08,
char DeviceName_09,
char DeviceName_10,
char DeviceName_11,
char DeviceName_12
).</vip>
}}

When using <vp>inline(<size>)</vp> on the <vp>pointer</vp> type the struct will contain <vp><size></vp> bytes, and the pointer will become a pointer to that field:

{{Example|
<vip>domains
mark =
mark(
integer Position,
pointer Data [8]
).</vip>
<vp>Data</vp> is pointer to 8 inlined bytes
The struct have the same layout as:
<vip>domains
mark2 =
mark2(
integer Position,
byte Data_1,
byte Data_2,
byte Data_3,
byte Data_4,
byte Data_5,
byte Data_6,
byte Data_7,
byte Data_8
).</vip>
And <vp>Data</vp> will point to <vp>Data_1</vp>.
}}

==== noDefaultConstructor ====

Used for a class to indicate that it should not have an implicit default constructor, and can thus be used to a class that does not have any public constructors at all. Valid for an object creating class declaration.

{{Example|
<vip>class classWithoutPublicConstructors : myInterface
open core
[noDefaultConstructor]
...
end class classWithoutPublicConstructors</vip>
}}

==== out ====

The argument is an output argument. Valid for a formal predicate argument.

{{Example|
<vip>predicates
pred : (string OutputArg [out]).</vip>
}}

==== programPoint ====

Used for a predicate or constructor declaration to indicate that it recieves an extra input argument which describes the place in a program (program point) where this predicate was called. This additional argument has programPoint type which is declared in the PFC core class like:

<vip>domains
programPoint = programPoint(hScopeDescriptor ClassDescriptor, string PredicateName, sourceCursor Cursor).
</vip>

The clause name of such predicate or constructor should have suffix "_explicit". Valid for a predicate or constructor declaration.

{{Example|
<vip>predicates
pred : (string String) [programPoint].
clauses
pred_explicit(ProgramPoint, String) :-
...
</vip>
}}

The <vp>programPoint</vp> attribute is described in more details in the description of [[Language Reference/Predicates#programPoint|Predicates]], and it is a vital part of the exception system, see [[Exception Handling]].

==== retired ====

The declared entity is retired. The string literal describes how to migrate from it. The entity does not exist anymore.

{{Example|
<vip>predicates
veryOldFasioned : (string Arg) [retired("Use newFasion instead")].</vip>
}}

==== sealed ====

Used for an interface to indicate that it cannot be supported by any other interface. This allows to create more efficient codes, because the compiler provides some optimization when using the objects of such type. Valid for an object creating class declaration as a construction interface.

{{Example|
<vip>interface myInterface
[sealed]
...
end interface myInterface

class myClass : myInterface
...
end class myClass</vip>
}}

==== union ====

Used for creating functor domains with several alternatives but no real functors. This should only be used to mimic C/C++ union structs in low-level interfacing. Valid for functor domain with several alternatives and alignment.

{{Example|
<vip>domains
u64var = align 4
u64(unsigned64 Value64);
u64_struct(unsigned Low32, unsigned High32)
[union].</vip>
}}

==== used ====

An unused local member can be marked <vp>used</vp> to prevent the compiler to issue a warning and remove the corresponding code. Valid for members.

{{Example|
<vip>predicates
seeminglyUnused : () [used].</vip>
}}

==== default ====

{{Template:NonReleased}}

It is problematic to update functor domains, if terms have been persisted in serialized form. Because new programs cannot deal with old serializations.

The two attributes <vp>default/1</vp> and <vp>retiredFunctor/1</vp> can help dealing with this problem.

The last arguments of a functor can have default values:

<vip>domains
ppp =
fct(
integer A,
real B,
ddd C,
integer* New [default([])],
real New2 [default(0)]
).</vip>

The default attribute does not change anything within the program; it only affects the deserialization. If during deserialization we meet the closing parenthesis too soon we supply default values for the remaining arguments.

'''Notice''' that this will only work for '''text''' deserialization.

See also [[Functor Domain Versioning]].

==== retiredFunctor ====

{{Template:NonReleased}}

Functor alternatives can be retired.

<vip>domains
ppp =
fct(integer A, real B, ddd C) [retiredFunctor(aaa::fct_ppp)];
fct2(integer A, ddd C, integer* New).</vip>

<vp>aaa::fct_ppp</vp> must be a predicate with this type (it can be an anonymous predicate):

<vip>predicates
fct_ppp : (integer A, real B, ddd C) -> ppp NewValue.</vip>

I.e. it takes the arguments of the old functor and returns a value in the functor domain.

In the program fct is does not exist at all, it is retired. But in the deserialization fct terms can still be handled: The arguments are parsed according to the types, and then the value is created by invoking <vp>aaa::fct_ppp</vp>.

This method will also work for binary serializations, provided:

* The old domain had more than one alternative (so there are functor numbers in the serialization)
* New alternatives are added last (to retain functor numbers)

It is however not recommend using binary serialization for inter-session persistence.

See also [[Functor Domain Versioning]].

Collection library

2016-11-03T13:14:11Z

Tbn: /* Keyword recognition */ typo

A collection is a value that contains a number (i.e. from zero to infinite) of other values.

Lists, sets, dictionaries, arrays, hash tables, (nondeterm) fact databases, etc are all collections.

A collection can also contain one value, but data types that by nature always contains exactly one value is not a collection. So a list with one element is a collection, but a variable which also contains one element is not a collection.

[[PFC]] contains an object oriented collection library with both persistent and modifiable collections. The collection library is based around a set of generic interfaces defining various conceptual collection types, and a number of classes implementing these interfaces.

== Persistent and Modifiable ==

Collections can be persistent or modifiable:

; Persistent
: A persistent collection never changes members. Meaning that when you insert or remove a member from persistent collection, you will receive a new collection and the old one will stay unchanged. Prolog lists is a characteristic example of persistent data types: When you match a list against a pattern to get the head and the tail, the original list stays intact; when you create a list from a new head and an existing list, both the new and the old list will exist.

; Modifiable
: Members can be added to and removed from a modifiable collection. Meaning that when you insert or remove a member from a modifiable collection, the old value of the collection is lost only the one exists. I.e. modifiable collections are updated destructively. Visual Prolog fact databases is a characteristic example of modifiable data types. When you assert or retract facts the database is modified and the original fact database is no longer accessible.

== Collection Interfaces & Classes ==

There is no fundamental difference in retrieving data from persistent and modifiable collection. The difference lies in the updating of the collections.

Therefore retrieval is done through interfaces that are shared by persistent and modifiable collections, whereas updating is done through separate persistent and modifiable interfaces.

<vp>collection</vp> is most fundamental interface for retrieving inspecting collections all collections supports this interface. It contains methods:
* <vp>isEmpty</vp> determining whether the collection is empty
* <vp>contains</vp> testing whether a certain element is in the collection
* <vp>tryGetFirst</vp> obtaining the first element in the collection.
* <vp>getAll_nd</vp> enumerating all elements in the collection.
* <vp>asList</vp> getting the collection in list form.

Notice that '''''first''''' means different things in different kinds of collections. In a hash table it may for example be the element with the first hash key.

Likewise, the order in which <vp>getAll_nd</vp> enumerates its elements depends on the collection kind.

Also notice that the performance of some operations may be very poor in some kind of collections. <vp>contains</vp> is for example a bad operation on a priority queue, because a priority queue not designed to determine membership.

All persistent collections also support the interface <vp>persistent</vp> and all modifiable collections supports the interface <vp>modifiable</vp>. <vp>persistent</vp> and <vp>modifiable</vp> have predicates with same names but different types, because the persistent version returns a new collection and the modifiable version doesn't return anything. These interfaces have methods:

* <vp>insert</vp>, <vp>insertList</vp> and <vp>insertCollection</vp> for inserting elements
* <vp>remove</vp>, <vp>removeList</vp> and <vp>removeCollection</vp> for removing elements
* <vp>tryRemoveFirst</vp> for removing the first element
* <vp>clear</vp> for removing all elements in the collection

=== set ===

A ''set'' is a collection of elements, which cannot contain duplicates. The fundamental set operation is test of membership. As such a set simply supports the <vp>collection</vp> interface and one of the interfaces <vp>persistent</vp> and <vp>modifiable</vp>.

* <vp>setP_redBlack</vp> implements persistent sets based on a red black tree representation.
* <vp>setM_redBlack</vp> implements modifiable sets based on a red black tree representation.

=== queue ===

A ''queue'' is a collection of elements which are ordered. The fundamental operation is getting the first element is the queue. Membership testing is typically inefficient. The interfaces of queues is similar to that of sets, supporting <vp>collection</vp> and one of the interfaces <vp>persistent</vp> and <vp>modifiable</vp>. The names are different to stress the difference in intension and efficeincy. And in future they may evolve differently. PFC contains two kinds of queues:

* ''queue'' is a "regular" FIFO (first-in-first-out) queue.
** <vp>queueP_fact</vp> implements a persistent FIFO queue based on a fact containing an algebraic queue
** <vp>queueM_fact</vp> implements a modifiable FIFO queue based on a nondeterm fact database

* ''priority queue'' is a queue where the first element is alwasy the element with hightst priority (i.e. the least, the greatest or based on a custom comparison).
** <vp>priorityQueueP_leftist</vp> implements a persistent priority queue
** <vp>priorityQueueM_leftist</vp> implements a modifiable priority queue
Both are based on a leftist tree (see [[wikipedia:Leftist tree]]).

=== map ===

A '''map''' is a function from ''keys'' to ''values''. Not all keys need have a value. The basic operations is setting, getting and try-getting the value associated with a certain key. When the value of a key is set the previous value of that key is "lost".

A map is a collection of (key,value)-tuples, so the <vp>collection</vp> predicates all deal with such tuples.

<vp>map</vp> is the basic interface for inspecting maps (persistent as well as modifiable). It supports <vp>collection</vp> of (key,value)-tuples and extends with predicates/properties:

* <vp>get</vp> and <vp>tryGet</vp> for getting the value associated with a key
* <vp>getKey_nd</vp> and <vp>getValue_nd</vp> for iterating the keys and values
* <vp>keyList</vp> and <vp>valueList</vp> for obtaining all the keys and values as lists.

<vp>mapP</vp> (persistent maps) and <vp>mapM</vp> (modifiable maps) supports <vp>map</vp> and either <vp>persistent</vp> or <vp>modifiable</vp>, and extends with:

* <vp>set</vp> for setting the value associated with a key (the previous value associated with that key is "lost")
* <vp>removeKey</vp> for removing a key and its associated value
* <vp>removeKeyList</vp> and <vp>removeKeyCollection</vp> for removing a number of keys and their associated values)

PFC contains persistent and modifiable map classes based on red-black trees:

* <vp>mapP_redBlack</vp>
* <vp>mapM_redBlack</vp>

== Usage examples ==

The examples in this section are inspired by the examples in ''The C5 Generic Collection Library for C# and CLI'', Niels Kokholm and Peter Sestoft, IT University Technical Report Series TR-2006-76, 2006.

=== Keyword recognition ===

It is often necessary to decide whether a word is member of some fixed collection of words. For example the keywords of a programming language, or frequent and therefore insignificant (so called stop-words) when indexing text.

Basically, we want to implement a class with a single deterministic predicate that can determine whether a word is a keyword:

<vip>class vipKeyword
predicates
isKeyword : (string Word) determ.
end class vipKeyword</vip>

It is a obvious choice to base the implementation on a set of keywords, because member-ship testing is the fundamantal operation of sets. The implementation can look like this:

<vip>implement vipKeyword
clauses
isKeyword(Word) :-
keywordSet:contains(Word).

class facts
keywordSet : setM{string Keyword} := initKeywordSet().

class predicates
initKeywordSet : () -> setM{string Keyword}.
clauses
initKeywordSet() = S :-
S = setM_redBlack::new(),
S:insertList(keywords).

constants
keywords : string* = ["as", "class", "clauses", ...].
end implement vipKeyword</vip>

<vp>isKeyword</vp> simply determines whether the the <vp>keywordSet</vp> <vp>contains</vp> the <vp>Word</vp> in question.

<vp>keywordSet</vp> is a (modifiable) set of strings, which is initialized to contain the actual keywords from the <vp>keywords</vp> constant.

Notice that you should be careful when initializing class facts like it is done above. Such initialization is done in an unpredictable order before entering the goal of the program. So first of all it is difficult to know which other parts of the program that has already been initialized. Secondly, the exception system is not initialized properly so exceptions will be reported in a rather low-level fasion.

=== Text Concordance ===

A text concordance is a list of words in a text and the lines on which the word occurs, i.e. an index of text.

We will represent that concordance as a map from <vp>Word</vp> to a set of <vp>Linenumber</vp>'s, where word is a string and line is an integer. For convenience we will define a domain:

<vip>domains
concordance = mapM{string Word, setM{integer Linenumber}}.</vip>

To build a concordance from a stream (typically a file), we iterate the lines in the file, and the words of the line. For each word we insert it in the relevant line number set, which will have to be created if it does not already exist:

<vip>class predicates
build : (inputStream Input) -> concordance Concordance.
clauses
build(Input) = Concordance :-
Concordance = mapM_redBlack::new(),
foreach
tuple(Line, Linenumber) = getLine_nd(Input, 1),
Word = getWord_nd(Line)
do
if LinenumberSet = Concordance:tryGet(Word) then
else
LinenumberSet = setM_redBlack::new(),
Concordance:set(Word, LinenumberSet)
end if,
LinenumberSet:insert(Linenumber)
end foreach.</vip>

Though not important for the main topic the iteration predicates are here:

<vip>class predicates
getLine_nd : (inputStream Input, integer NextLine) -> tuple{string Line, integer Linenumber} nondeterm.
clauses
getLine_nd(Input, _NextLine) = _ :-
Input:endOfStream(),
!,
fail.

getLine_nd(Input, NextLine) = tuple(Line, NextLine) :-
Line = Input:readLine().

getLine_nd(Input, NextLine) = getLine_nd(Input, NextLine+1).

class predicates
getWord_nd : (string Line) -> string Word nondeterm.
clauses
getWord_nd(Line) = getWord2_nd(First, Rest) :-
string::frontToken(Line, First, Rest).

class predicates
getWord2_nd : (string First, string Rest) -> string Word nondeterm.
clauses
getWord2_nd(First, _Rest) = string::toLowerCase(First) :-
string::length(First) > 2, % only words with more than 2 letters
not(regexp::search("[^a-zA-Z]", First, _, _)). % not a word if it contains non-letters

getWord2_nd(_First, Rest) = getWord_nd(Rest).</vip>

From a concordance we can print an index, by iterating the <vp>(Word, LinenumberSet)</vp> tuples in the <vp>Concordance</vp>, and the <vp>Linenumber</vp>'s in the <vp>LinenumberSet</vp>'s. Since both the maps and the sets are based on red-black trees everything is automatically sorted for us:

<vip>class predicates
print : (outputStream Output, concordance Concordance).
clauses
print(Output, Concordance) :-
foreach tuple(Word, LinenumberSet) = Concordance:getAll_nd() do
Output:writef("%:\n", Word),
foreach Linenumber = LinenumberSet:getAll_nd() do
Output:writef(" %\n", Linenumber)
end foreach,
Output:write("\n")
end foreach.</vip>

== References ==

* [http://www.itu.dk/research/c5/ The C5 Generic Collection Library for C# and CLI]

[[Category:Data types and handling]]

Collection library

2016-11-03T12:40:42Z

Tbn: /* queue */ typo

A collection is a value that contains a number (i.e. from zero to infinite) of other values.

Lists, sets, dictionaries, arrays, hash tables, (nondeterm) fact databases, etc are all collections.

A collection can also contain one value, but data types that by nature always contains exactly one value is not a collection. So a list with one element is a collection, but a variable which also contains one element is not a collection.

[[PFC]] contains an object oriented collection library with both persistent and modifiable collections. The collection library is based around a set of generic interfaces defining various conceptual collection types, and a number of classes implementing these interfaces.

== Persistent and Modifiable ==

Collections can be persistent or modifiable:

; Persistent
: A persistent collection never changes members. Meaning that when you insert or remove a member from persistent collection, you will receive a new collection and the old one will stay unchanged. Prolog lists is a characteristic example of persistent data types: When you match a list against a pattern to get the head and the tail, the original list stays intact; when you create a list from a new head and an existing list, both the new and the old list will exist.

; Modifiable
: Members can be added to and removed from a modifiable collection. Meaning that when you insert or remove a member from a modifiable collection, the old value of the collection is lost only the one exists. I.e. modifiable collections are updated destructively. Visual Prolog fact databases is a characteristic example of modifiable data types. When you assert or retract facts the database is modified and the original fact database is no longer accessible.

== Collection Interfaces & Classes ==

There is no fundamental difference in retrieving data from persistent and modifiable collection. The difference lies in the updating of the collections.

Therefore retrieval is done through interfaces that are shared by persistent and modifiable collections, whereas updating is done through separate persistent and modifiable interfaces.

<vp>collection</vp> is most fundamental interface for retrieving inspecting collections all collections supports this interface. It contains methods:
* <vp>isEmpty</vp> determining whether the collection is empty
* <vp>contains</vp> testing whether a certain element is in the collection
* <vp>tryGetFirst</vp> obtaining the first element in the collection.
* <vp>getAll_nd</vp> enumerating all elements in the collection.
* <vp>asList</vp> getting the collection in list form.

Notice that '''''first''''' means different things in different kinds of collections. In a hash table it may for example be the element with the first hash key.

Likewise, the order in which <vp>getAll_nd</vp> enumerates its elements depends on the collection kind.

Also notice that the performance of some operations may be very poor in some kind of collections. <vp>contains</vp> is for example a bad operation on a priority queue, because a priority queue not designed to determine membership.

All persistent collections also support the interface <vp>persistent</vp> and all modifiable collections supports the interface <vp>modifiable</vp>. <vp>persistent</vp> and <vp>modifiable</vp> have predicates with same names but different types, because the persistent version returns a new collection and the modifiable version doesn't return anything. These interfaces have methods:

* <vp>insert</vp>, <vp>insertList</vp> and <vp>insertCollection</vp> for inserting elements
* <vp>remove</vp>, <vp>removeList</vp> and <vp>removeCollection</vp> for removing elements
* <vp>tryRemoveFirst</vp> for removing the first element
* <vp>clear</vp> for removing all elements in the collection

=== set ===

A ''set'' is a collection of elements, which cannot contain duplicates. The fundamental set operation is test of membership. As such a set simply supports the <vp>collection</vp> interface and one of the interfaces <vp>persistent</vp> and <vp>modifiable</vp>.

* <vp>setP_redBlack</vp> implements persistent sets based on a red black tree representation.
* <vp>setM_redBlack</vp> implements modifiable sets based on a red black tree representation.

=== queue ===

A ''queue'' is a collection of elements which are ordered. The fundamental operation is getting the first element is the queue. Membership testing is typically inefficient. The interfaces of queues is similar to that of sets, supporting <vp>collection</vp> and one of the interfaces <vp>persistent</vp> and <vp>modifiable</vp>. The names are different to stress the difference in intension and efficeincy. And in future they may evolve differently. PFC contains two kinds of queues:

* ''queue'' is a "regular" FIFO (first-in-first-out) queue.
** <vp>queueP_fact</vp> implements a persistent FIFO queue based on a fact containing an algebraic queue
** <vp>queueM_fact</vp> implements a modifiable FIFO queue based on a nondeterm fact database

* ''priority queue'' is a queue where the first element is alwasy the element with hightst priority (i.e. the least, the greatest or based on a custom comparison).
** <vp>priorityQueueP_leftist</vp> implements a persistent priority queue
** <vp>priorityQueueM_leftist</vp> implements a modifiable priority queue
Both are based on a leftist tree (see [[wikipedia:Leftist tree]]).

=== map ===

A '''map''' is a function from ''keys'' to ''values''. Not all keys need have a value. The basic operations is setting, getting and try-getting the value associated with a certain key. When the value of a key is set the previous value of that key is "lost".

A map is a collection of (key,value)-tuples, so the <vp>collection</vp> predicates all deal with such tuples.

<vp>map</vp> is the basic interface for inspecting maps (persistent as well as modifiable). It supports <vp>collection</vp> of (key,value)-tuples and extends with predicates/properties:

* <vp>get</vp> and <vp>tryGet</vp> for getting the value associated with a key
* <vp>getKey_nd</vp> and <vp>getValue_nd</vp> for iterating the keys and values
* <vp>keyList</vp> and <vp>valueList</vp> for obtaining all the keys and values as lists.

<vp>mapP</vp> (persistent maps) and <vp>mapM</vp> (modifiable maps) supports <vp>map</vp> and either <vp>persistent</vp> or <vp>modifiable</vp>, and extends with:

* <vp>set</vp> for setting the value associated with a key (the previous value associated with that key is "lost")
* <vp>removeKey</vp> for removing a key and its associated value
* <vp>removeKeyList</vp> and <vp>removeKeyCollection</vp> for removing a number of keys and their associated values)

PFC contains persistent and modifiable map classes based on red-black trees:

* <vp>mapP_redBlack</vp>
* <vp>mapM_redBlack</vp>

== Usage examples ==

The examples in this section are inspired by the examples in ''The C5 Generic Collection Library for C# and CLI'', Niels Kokholm and Peter Sestoft, IT University Technical Report Series TR-2006-76, 2006.

=== Keyword recognition ===

It is often necessary to decide whether a word is member of some fixed collection of words. For example the keywords of a programming language, or frequent and therefore insignificant (so called stop-words) when indexing text.

Basically, we want to implement a class with a single deterministic predicate that can determine whether a word is a keyword:

<vip>class vipKeyword
predicates
isKeyword : (string Word) determ.
end class vipKeyword</vip>

It is a obvious choice to base the implementation on a set of keywords, because member-ship testing is the fundamantal operation of sets. The implementation can look like this:

<vip>implement vipKeyword
clauses
isKeyword(Word) :-
keywordSet:contains(Word).

class facts
keywordSet : setM{string Keyword} := initKeywordSet().

class predicates
initKeywordSet : () -> setM{string Keyword}.
clauses
initKeywordSet() = S :-
S = setM_redBlack::new(),
S:insertList(keywords).

constants
keywords : string* = ["as", "class", "clauses", ...].
end implement vipKeyword</vip>

<vp>isKeyword</vp> simply determines whether the the <vp>keywordSet</vp> <vp>contains</vp> the <vp>Word</vp> in question.

<vp>keywordSet</vp> is a (modifiable) set of strings, which is initialized to contain the actual keywords from the <vp>keywords</vp> constant.

Notice that you should be carefull when initializing class facts like it is done above. Such initialization is done in an unpredictable order before entering the goal of the program. So first of all it is difficult to know which other parts of the program that has already been initialized. Secondly, the exception system is not initialized properly so exceptions will be reported in a rather low-level fasion.

=== Text Concordance ===

A text concordance is a list of words in a text and the lines on which the word occurs, i.e. an index of text.

We will represent that concordance as a map from <vp>Word</vp> to a set of <vp>Linenumber</vp>'s, where word is a string and line is an integer. For convenience we will define a domain:

<vip>domains
concordance = mapM{string Word, setM{integer Linenumber}}.</vip>

To build a concordance from a stream (typically a file), we iterate the lines in the file, and the words of the line. For each word we insert it in the relevant line number set, which will have to be created if it does not already exist:

<vip>class predicates
build : (inputStream Input) -> concordance Concordance.
clauses
build(Input) = Concordance :-
Concordance = mapM_redBlack::new(),
foreach
tuple(Line, Linenumber) = getLine_nd(Input, 1),
Word = getWord_nd(Line)
do
if LinenumberSet = Concordance:tryGet(Word) then
else
LinenumberSet = setM_redBlack::new(),
Concordance:set(Word, LinenumberSet)
end if,
LinenumberSet:insert(Linenumber)
end foreach.</vip>

Though not important for the main topic the iteration predicates are here:

<vip>class predicates
getLine_nd : (inputStream Input, integer NextLine) -> tuple{string Line, integer Linenumber} nondeterm.
clauses
getLine_nd(Input, _NextLine) = _ :-
Input:endOfStream(),
!,
fail.

getLine_nd(Input, NextLine) = tuple(Line, NextLine) :-
Line = Input:readLine().

getLine_nd(Input, NextLine) = getLine_nd(Input, NextLine+1).

class predicates
getWord_nd : (string Line) -> string Word nondeterm.
clauses
getWord_nd(Line) = getWord2_nd(First, Rest) :-
string::frontToken(Line, First, Rest).

class predicates
getWord2_nd : (string First, string Rest) -> string Word nondeterm.
clauses
getWord2_nd(First, _Rest) = string::toLowerCase(First) :-
string::length(First) > 2, % only words with more than 2 letters
not(regexp::search("[^a-zA-Z]", First, _, _)). % not a word if it contains non-letters

getWord2_nd(_First, Rest) = getWord_nd(Rest).</vip>

From a concordance we can print an index, by iterating the <vp>(Word, LinenumberSet)</vp> tuples in the <vp>Concordance</vp>, and the <vp>Linenumber</vp>'s in the <vp>LinenumberSet</vp>'s. Since both the maps and the sets are based on red-black trees everything is automatically sorted for us:

<vip>class predicates
print : (outputStream Output, concordance Concordance).
clauses
print(Output, Concordance) :-
foreach tuple(Word, LinenumberSet) = Concordance:getAll_nd() do
Output:writef("%:\n", Word),
foreach Linenumber = LinenumberSet:getAll_nd() do
Output:writef(" %\n", Linenumber)
end foreach,
Output:write("\n")
end foreach.</vip>

== References ==

* [http://www.itu.dk/research/c5/ The C5 Generic Collection Library for C# and CLI]

[[Category:Data types and handling]]

Introduction to Classes and Objects

2016-11-03T11:53:29Z

Tbn: /* Inheritance */

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

==Object Model==

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

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

Consider this interface definition:

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

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

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

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

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

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

<vip>implement person
facts
name : string.

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

clauses
getName() = name.

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

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

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

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

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

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

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

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

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

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

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

clauses
getCreatedCount() = createdCount.

facts
name : string.

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

clauses
getName() = name.

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

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

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

==Modules==

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

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

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

==Creation and Access==

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

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

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

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

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

==Interfaces are Object Types==

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

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

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

==Multiple Implementations==

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

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

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

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

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

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

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

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

==Subsumption Polymorphism==

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

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

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

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

==Supports (Type Extension)==

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

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

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

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

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

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

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

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

An interface can support several other interfaces, meaning that:

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

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

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

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

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

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

==Inheritance==

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

<vip>implement user
inherits
person

facts
password : string.

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

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

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

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

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

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

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

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

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

clauses
getName() = person:getName().

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

...
end implement user_class</vip>

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

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

*First of all I have written more code.

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

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

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

==Final Remarks==

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

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

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

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

Introduction to Classes and Objects

2016-11-03T11:51:27Z

Tbn: /* Supports (Type Extension) */

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

==Object Model==

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

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

Consider this interface definition:

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

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

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

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

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

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

<vip>implement person
facts
name : string.

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

clauses
getName() = name.

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

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

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

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

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

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

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

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

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

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

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

clauses
getCreatedCount() = createdCount.

facts
name : string.

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

clauses
getName() = name.

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

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

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

==Modules==

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

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

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

==Creation and Access==

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

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

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

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

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

==Interfaces are Object Types==

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

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

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

==Multiple Implementations==

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

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

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

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

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

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

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

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

==Subsumption Polymorphism==

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

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

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

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

==Supports (Type Extension)==

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

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

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

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

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

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

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

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

An interface can support several other interfaces, meaning that:

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

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

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

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

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

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

==Inheritance==

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

<vip>implement user
inherits
person

facts
password : string.

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

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

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

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

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

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

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

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

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

clauses
getName() = person:getName().

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

...
end implement user_class</vip>

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

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

*First of all I have written more code.

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

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

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

==Final Remarks==

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

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

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

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

Introduction to Classes and Objects

2016-11-03T11:50:48Z

Tbn: /* Supports (Type Extension) */

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

==Object Model==

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

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

Consider this interface definition:

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

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

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

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

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

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

<vip>implement person
facts
name : string.

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

clauses
getName() = name.

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

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

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

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

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

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

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

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

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

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

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

clauses
getCreatedCount() = createdCount.

facts
name : string.

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

clauses
getName() = name.

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

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

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

==Modules==

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

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

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

==Creation and Access==

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

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

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

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

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

==Interfaces are Object Types==

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

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

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

==Multiple Implementations==

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

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

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

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

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

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

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

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

==Subsumption Polymorphism==

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

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

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

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

==Supports (Type Extension)==

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

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

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

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

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

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

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

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

An interface can support several other interfaces, meaning that:

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

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

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

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

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

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

==Inheritance==

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

<vip>implement user
inherits
person

facts
password : string.

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

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

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

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

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

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

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

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

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

clauses
getName() = person:getName().

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

...
end implement user_class</vip>

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

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

*First of all I have written more code.

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

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

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

==Final Remarks==

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

*Objects can support further interfaces in the implementation.

*Finalizers that are executed on storage reclaim.

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

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

Compound and List Domains

2016-11-03T10:32:31Z

Tbn: /* Multi-Level Compound Domains */

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

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

==Compound Domains and Functors==

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

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

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

and then simply writing e.g.

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

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

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

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

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

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

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

==Unification of Compound Domains==

A compound value can unify either with a simple variable or with a compound value that matches it(perhaps containing variables as parts of its internal structure). This means you can use a compound value to pass the whole collection of items as a single value, and then use unification to pick them apart. For example, <vp>date("April", 14, 1960)</vp> matches <vp>X</vp> and binds <vp>X</vp> to <vp>date("April",14,1960)</vp>. Also <vp>date("April", 14, 1960)</vp> matches <vp>date(Mo, Da, Yr)</vp> and binds <vp>Mo</vp> to <vp>"April"</vp>, <vp>Da</vp> to <vp>14</vp>, and <vp>Yr</vp> to <vp>1960</vp>.

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

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

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

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

predicates
run :().
end class

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

goal
my::run.</vip>

==Treating Several Items as One==

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

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

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

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

which can be interpreted as

John owns a horse named Blacky.

The compound values in these two examples are

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

and

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

If you had instead written two facts:

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

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

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

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

===An Example Using Compound Domains===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==Declaring Compound Domains==

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

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

and

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

you could query the system with this goal:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'''Note''':

*The alternatives are separated by semicolons.

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

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

===Multi-Level Compound Domains===

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

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

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

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

In the old domain declaration

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

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

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

which leads to the following declarations:

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

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

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

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

==Compound Mixed-Domain Declarations==

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

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

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

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

===Multiple-Type Arguments===

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

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

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

Visual Prolog does not allow the following domain declaration:

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

===Lists===

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

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

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

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

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

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

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

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

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

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

<vip>domains
integer_list = integer*.

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

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

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

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

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

==Summary==

These are the important points covered in this tutorial:

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

*Simple values are numbers, strings, etc.

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

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

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

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

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

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

[[ru:Cоставные Домены и Списки]]
[[Category:Data types and handling]]