TEACH PROGLECT4 Aaron Sloman Oct 1998
Revised 6 Nov 2000
The Pop-11 database and its uses.
See TEACH * PROGLECT1, PROGLECT2, PROGLECT3,
CONTENTS
-- The Pop-11 matcher
-- Some simple examples showing testing the contents of a list
-- Examples using variables to remember what was matched
-- The matcher can also dig into embedded lists
-- " for use outside conditionals">The matcher arrow "-->" for use outside conditionals
-- The matcher can also use restrictions on variables
-- The Pop-11 database
-- Simple database examples
-- Some useful database procedures
-- Iterating over the database with foreach
-- Examples using foreach
-- Matching lists of patterns consistently: forevery
-- One way to fix two_away
-- Another way to fix the problem
-- Using the database to do list processing
-- Allpresent and which_values
-- More on the database
-- -- Query procedures
-- Database reminders
-- Next task: build a more convenient interface. See TEACH RIVERCHAT
-- Some examples in the library-- The Pop-11 matcher -------------------------------------------------
One of the features of Pop-11 which makes it particularly useful for
teaching is the pattern matcher. This allows you to access the contents
of complex list structures relatively easily.
Contrast this:
vars list;
[the cat sat on the very old mat] -> list;
vars third, rest;
if list matches ![= = ?third ??rest] then
rest =>
third =>
endif;
With this
if length(list) >= 3 then
hd(tl(tl(list))) -> third;
tl(tl(tl(list))) -> rest;
rest =>
third =>
endif;
Code written with the pattern matcher is often much clearer and easier
to keep bug free than code using the lower level list processing
procedures like hd and tl. However it may run a bit more slowly.
(There are always tradeoffs.)
The use of the pattern matcher makes it easy to provide a simple but
powerful "database" mechanism.
For more on the matcher see
TEACH MATCHES, TEACH MATCHES2, HELP MATCHES
PRIMER, chapter 7
The matcher is also used in the far more powerful Poprulebase system,
described in TEACH RULEBASE.
-- Some simple examples showing testing the contents of a list --------
The matcher basically compares two lists of items in the same order:
[1 2 3] matches [1 2 3] =>
[1 2 3 4] matches [1 2 3] =>
[1 2 3] matches [1 2 3 4] =>
[1 2 3] matches [3 2 1] =>
All those examples would have worked with "=" instead of "matches", e.g.
[1 2 3] = [1 2 3] =>
[1 2 3 4] = [1 2 3] =>
However "matches" is more powerful. It can also compare a list with a
"template" or "pattern".
These contain special pattern elements which allow the matching process
to be more flexible.
There are two anonymous pattern elements (jokers) which will match
anything but will not keep any record of what they have matched, unlike
pattern elements with variables that remember what they matched:
"=" matches exactly one element
"==" matches an arbitrary number of elements
(The latex Max Clowes used to say: "Gobble one" vs "Gobble many").
[1 2 3] matches [= 2 ==] =>
[1 2 3] matches [== 2 ==] =>
[1 2 3] matches [== 2 =] =>
[1 2 3 4 5] matches [== 2 ==] =>
[1 2 3 4 5] matches [== 1 2 ==] =>
A "segment" pattern element matches an arbitrary sublist (segment of
the list), including an EMPTY sublist, as in the last case.
Compare:
[steve is a teacher ] matches [ == is a == ] =>
[steve is a teacher ] matches [ == is == a == ] =>
[fred is not a computer] matches [ == is a == ] =>
[fred is not a computer] matches [ == is = a == ] =>
-- Examples using variables to remember what was matched --------------
Create a list:
vars list = [the cat sat on the very old mat];
We now look at various ways of accessing its components using the
pattern matcher:
vars between;
list matches [== cat ??between old ==] =>
between =>
list matches [== the ??between old ==] =>
between =>
list matches [== = the ??between old ==] =>
between =>
list matches [== = the cat ??between old ==] =>
between =>
-- The matcher can also dig into embedded lists -----------------------
vars list = [[a stich in time] saves [twenty nine]];
vars xxx, yyy, zzz;
list matches [[a ??xxx time] ?yyy [??zzz]] =>
xxx =>
yyy =>
zzz =>
What about this
list matches [[a ??xxx time] ??yyy [??zzz]] =>
xxx =>
yyy =>
zzz =>
and this
list matches [[a ??xxx time] ??yyy ?zzz] =>
xxx =>
yyy =>
zzz =>
and this
list matches [[a ??xxx time] ??yyy ??zzz] =>
xxx =>
yyy =>
zzz =>
Warning: two adjacent segment pattern elements will produce undefined
results.
" for use outside conditionals">-- The matcher arrow "-->" for use outside conditionals --------------
See TEACH MATCHES2
Note, we can use "-->" if we are not interested in WHETHER the match
holds, only what is in the list.
vars x;
[a b c] --> [a b ?x];
x=>
But mishaps may occur.
[a b c] --> [a b c d];
The syntax for pattern elements is the same whether you use "matches"
or "-->" or the database constructs based on the matcher described
below (and in Chapter 7 of the Pop-11 primer).
-- The matcher can also use restrictions on variables -----------------
vars
item, item2,
testlist = ['a string' 4 cat [a list] 3 dog];
testlist --> [== ?item:isnumber ==];
item =>
testlist --> [== ?item:isstring ==];
item =>
testlist --> [== ?item:isword ==];
item =>
testlist --> [== ?item:islist ==];
item =>
vars rest;
testlist --> [??item:3 ??rest];
item =>
rest =>
For more on pattern elements and restrictions see
HELP MATCHES
-- The Pop-11 database ------------------------------------------------
THE DATABASE AS A LIST OF LISTS OF INFORMATION
The database package provides a subset of such facilities. See
TEACH * DATABASE
Lists are a derived data-type, based on Pop-11 pairs, together with a
host of procedures and syntax constructs that treat chained sets of
pairs as if they were one extended object, e.g.
Procedures for lists:
hd,
tail,
length,
applist,
rev
member
last
<>
=
matches
Syntactic constructs for use with lists, e.g.
for <var> in <list> do .... endfor,
for <var> on <list> do .... endfor,
See HELP FOR
Similarly Pop-11 databases are a derived data-type, based on Pop-11
lists, together with a collection of procedures and syntactic constructs
that treat a list of lists as if it were one object, e.g.
Procedures for the database:
add,
alladd,
remove,
flush,
present,
lookup,
allpresent,
which_values
Syntactic constructs for the database:
foreach <pattern> do ... endforeach, etc.
forevery <list of patterns> do ... endforevery, etc.
The database concept depends essentially on the use of the Pop-11
pattern matcher.
The matcher compares ONE list of information with a pattern.
The database can be thought of as containing MANY lists that can be
compared with the same pattern. This is the simplest use of the
database.
E.g. you may wish to check whether the database contains at least one
item that matches a given pattern.
Or you may wish to find ALL the items that match a pattern.
In either case, pattern variables may be used to extract information
from the items in the database, just as a pattern can extract
information from a single list.
Likewise it is possible to remove from the database an item that matches
a pattern, or to remove ALL items that match a pattern.
There are database procedures that take a pattern and compare it with
all the items in the database, or all until something is found that
matches.
There are more complex database procedures that take a LIST of
patterns and try to find all the different ways those patterns can
consistently be matched against database entries.
Thus you can find if someone is the maternal grandfather of
someone else by using a list containing these two patterns:
[ [father ?person1 ?person2] [mother ?person2 ?person3] ]
Matching consistently means that the matcher should produce the same
values for the same variables.
I.e. after the first pattern has matched something it constrains
what can match the second pattern.
Note: rule-based programming (as explained in TEACH * RULEBASE and
related files, is a generalisation of database programming.)
So is Prolog, the logic programming language.
-- Simple database examples -------------------------------------------
database ==>
add([steve is a teacher]);
add([steve likes apple pie]);
database ==>
add([fred is a teacher]);
add([fred likes jam tart]);
add([julie is a teacher]);
add([julie likes baked haddock]);
database ==>
Compare the simple print arrow -- the printing is not so easy to read
when the list of lists is too long to fit on one line.
database =>
present([steve is a teacher]) =>
present([steve likes baked haddock]) =>
present([aaron likes jam tart]) =>
present( ![julie likes ??x] ) =>
x =>
it =>
present( ![??x likes apple pie] ) =>
x =>
it =>
vars person, what;
present( ![??person likes ??what] ) =>
The procedure present returns a true or false result, so that it can be
used in conditionals. The procedure lookup does not return a result. It
is used only for its 'side-effects", i.e. setting variables in a pattern
to record what was found in the database, just as "-->" is used only for
its side effects whereas matches producs a true/false result.
lookup( ![fred likes ??x] ); ;;; use semi-colon, not print arrow
x =>
lookup( ![mary likes ??x] ); ;;; use semi-colon, not print arrow
The procedures remove and flush also produce no result. They take a list
or a pattern and remove items from the database. Only one item, the
first one found to match the pattern, is removed by remove. By contrast
flush removes everything that matches the pattern. The item removed in
the first case is assigned to the variable it. The items removed by
flush are put in a list (which may be empty) and the list is assigned to
the variable them.
remove([== likes ==]);
database ==>
it =>
flush([== likes ==]);
database ==>
them ==>
If there is nothing to match, then remove produces a mishap:
remove([== likes ==]);
;;; MISHAP - ATTEMPT TO REMOVE NON-EXISTENT ITEM
;;; INVOLVING: [== likes ==]
;;; DOING : remove runproc ....
Whereas flush does not mishap, but if nothing in the database matches
its argument, it assigns the empty list to them.
database ==>
flush([== elephant ==]);
database ==>
them ==>
Don't confuse flush, which removes all items matching one pattern, and
allremove, which takes a list of patterns, and removes one item matching
each pattern.
[[julie is a teacher] [fred is a pilot] [steve is a nurse]]
-> database;
vars list1, list2;
allremove(![ [fred ??list1] [steve ??list2]]);
database ==>
them ==>
list1 ==>
list2 ==>
-- Some useful database procedures ------------------------------------
add(ITEM)
The item should be a list. It is added to the database.
It is also assigned to the global variable "it", which is used
for the last database item accessed.
alladd(LIST)
Takes a list of database items (all lists) and adds them to
the database. It assigns the list to the global variable "them".
present(PATTERN) -> BOOLEAN
Tries everything till an item is found that matches
I.e. looks for ONE thing.
returns a true-false result
If it finds something that matches the pattern it
(a) sets variables in the pattern
(b) sets the variable "it" to have the item as its value
(c) returns immediately with a true result.
It could be defined thus:
define present(pattern) -> boolean;
lvars item;
for item in database do
if item matches pattern then
item -> it;
true -> boolean;
return();
endif;
endfor;
;;; failed to find match, so return false
false -> boolean;
enddefine;
foreach PATTERN do ... endforeach;
Tries EVERY ITEM in the database
Every time an item is found that matches PATTERN foreach
(a) sets variables in the pattern
(b) sets the variable "it" to have the item as its value
(c) performs the action, using the values of the variables.
lookup(PATTERN)
NB This has no result. It is like "-->"
It looks for at least ONE thing that matches the pattern.
Generates an error if it fails
If it succeeds
(a) sets variables in the pattern
(b) sets the variable "it"
It could be defined thus
define lookup(pattern);
unless present(pattern) then
mishap(pattern, 1, 'LOOKUP FAILURE')
endunless
enddefine;
Example:
alladd([ [a b c d] [d c b a] [a b d c] ]);
vars x;
lookup([= ?x b ==]);
x =>
it =>
lookup([= ?x e ==]);
Extract from TEACH PRIMER
procedure returns iterates over mishap on
a boolean the database failure
---------------------------------------------------------
matches yes no no
--> no no yes
present yes yes no
lookup no yes yes
remove(PATTERN)
Searches for one thing in the database and removes it
If it succeeds
(a) sets variables in the pattern
(b) sets the variable "it"
flush(PATTERN)
removes everything that matches
sets the variable "them" to be a list of items removed.
[] -> database;
alladd([ [a b c d] [d c b a] [a b d c] [1 b 3 d 5]]);
database ==>
flush([ == b == d == ]);
them =>
database ==>
allremove(LIST)
Given a list of patterns (or lists) makes sure that it can
remove at least one item for each of them, and does so.
If not, generates a mishap.
-- Iterating over the database with foreach ---------------------------
Formats:
foreach <pattern> do <actions> endforeach
foreach <pattern> in <list> do <actions> endforeach
or
foreach ! <pattern> do <actions> endforeach
foreach ! <pattern> in <list> do <actions> endforeach
This tries matching the <pattern> against every item in the database.
Every time the match is succesful it performs actions.
You can treat
foreach <pattern> do <actions> endforeach
as approximately equivalent to this:
lvars item;
for item in database do
if item matches <pattern> then
<actions>
endif;
endfor;
Note that this uses the variable database as global.
In fact it is a bit more complicated than that because foreach ensures
that the original database is used throughout the loop since the
<actions> can change the database if there are add or remove actions
included.
-- Examples using foreach ---------------------------------------------
define people();
;;; clear the database and set up a collection of "initial" facts
[] -> database;
add([joe isa man]);
add([jill isa woman]);
add([joe lives_in london]);
add([jill lives_in brighton]);
add([bill isa man]);
add([sue isa woman]);
add([bill lives_in london]);
add([sue lives_in paris]);
enddefine;
people();
We have information about several women in the database, but if you do
vars x;
present([?x isa woman])=>
x =>
and then do it again
present([?x isa woman])=>
x =>
you'll see that it always finds the same thing (provided the database has not
changed in between).
But foreach finds them all:
vars x;
foreach [?x isa woman] in database do x => endforeach;
We could make a list of all of them
vars x, list;
[% foreach [?x isa woman] in database do x endforeach %] -> list;
list =>
It is possible to use nested foreach lists.
[[connects room1 room2]
[connects room1 room3]
[connects room2 room4]
[connects room3 room5]
[connects room3 room4]
[connects room4 room6]] -> database;
vars connections;
vars r1, r2, r3;
[%
foreach ! [connects ?r1 ?r2] do
foreach ! [connects ^r2 ?r3] do
[Two away ^r1 ^r3]
endforeach
endforeach
%] -> connections;
connections ==>
Note that for every match of the FIRST pattern the second one is
tried against ALL the database items.
This can be abbreviated using forevery, which takes a list of lists
in one loop.
vars connections;
vars r1, r2, r3;
[%
forevery ! [[connects ?r1 ?r2][connects ?r2 ?r3]] do
[Two away ^r1 ^r3]
endforevery
%] -> connections;
connections ==>
Forevery can be used with an arbitrarily long list of patterns. N
patterns corresponds to N nested loops. (As N increases it gets
slower and slower...).
If K is the length of the database there are N x K matches to do.
Compare which_values
which_values( ! [?r1 ?r3], ! [[connects ?r1 ?r2][connects ?r2 ?r3]] )
==>
This is defind in terms of forevery, approximately like this:
define which_values(Vars, Patternlist) -> List;
;;; Vars should be a list of variables prefixed by "?" transformed by "!"
;;; Patternlist should be a list of patterns, the whole having been transformed
;;; by "!"
if ispair(Vars) then
if ispair(Patternlist) then
[%forevery Patternlist do
lvars list;
[%for list on Vars do
if hd(list) == "?" or hd(list) == "??" then
valof(hd(tl(list)))
endif
endfor%]
endforevery%] -> List
else mishap('LIST OF PATTERNS NEEDED', [^Patternlist])
endif;
else
mishap('LIST NEEDED FOR "WHICH_VALUES"', [^Vars] )
endif;
enddefine;
-- Matching lists of patterns consistently: forevery ------------------
This example introduces the trade-off between forms of representation
and choice of algorithms.
Searching in the database for an item or set of items that match a given
pattern is a relatively trivial task. Far more complex is finding a
consistent way of matching a collection of patterns against a database.
For example you could have a database of information about which rooms
are connected with which.
[[connects room1 room2]
[connects room1 room3]
[connects room2 room4]
[connects room3 room5]
[connects room3 room4]
[connects room4 room6]] -> database;
Graphically
room3 --- room1 --- room2
| | |
| +----- room4 ----+
| |
room5 room6
Now suppose you wanted to find routes to all the rooms that are two
links away from a given room, you can use the forevery construct in a
procedure like this:
define two_away(room) -> list;
;;; return a list of two-step routes from room
lvars r1, r2;
[%
forevery ! [[connects ^room ?r1][connects ?r1 ?r2]] do
[^room ^r1 ^r2]
endforevery
%] -> list;
enddefine;
test it
two_away("room1") ==>
But this procedure has a bug. What is it and how can it be fixed?
It does not find all the routes:
two_away("room3") ==>
Why not?
-- One way to fix two_away --------------------------------------------
In deciding how to fix two_away you have to consider whether to change
the representation of information in the database. For example the
information is represented asymetrically, insofar as we have
represented the fact
[connects room1 room3]
but not the fact
[connects room3 room1]
which is in a sense the same fact, expressed differently. You could try
extending the database to include such "reverse" facts, e.g.
[[connects room1 room2]
[connects room2 room1]
[connects room1 room3]
[connects room3 room1]
[connects room2 room4]
;;; and so on
[connects room3 room5]
[connects room3 room4]
[connects room4 room6]] -> database;
and then try out the procedure two_away with the same example as before
two_away("room3") ==>
This now gives more answers.
It would be desirable to rule out answers like this:
[room1 room3 room1]
Or would it?
-- Another way to fix the problem -------------------------------------
Another way is to use the original database, but extend the procedure
two_away to try all the combinations explicitly:
[[connects room1 room2]
[connects room1 room3]
[connects room2 room4]
[connects room3 room5]
[connects room3 room4]
[connects room4 room6]] -> database;
database ==>
define two_away_symmetric(room) -> list;
;;; return a list of two-step routes from room
lvars r1, r2;
[%
forevery ! [[connects ^room ?r1][connects ?r1 ?r2]] do
[^room ^r1 ^r2]
endforevery;
;;; keep the same first condition, but change the second
forevery ! [[connects ^room ?r1][connects ?r2 ?r1]] do
[^room ^r1 ^r2]
endforevery;
;;; now reverse the first condition, and try both orders
;;; for the second
forevery ! [[connects ?r1 ^room][connects ?r1 ?r2]] do
[^room ^r1 ^r2]
endforevery;
forevery ! [[connects ?r1 ^room][connects ?r2 ?r1]] do
[^room ^r1 ^r2]
endforevery;
%] -> list;
enddefine;
room3 --- room1 --- room2
| | |
| +----- room4 ----+
| |
room5 room6
Test that:
two_away_symmetric("room1") ==>
two_away_symmetric("room3") ==>
That is an example of a trade-off between economy of representation and
economy of processing.
-- Using the database to do list processing ---------------------------
How do you remove repeated elements from a list of lists?
One way to "prune" the list would be to make the redundant list
temporarily the database, then flush out all repetitions, like this:
define prune_list(list) -> newlist;
vars database = list;
lvars item, donelist = [];
for item in list do
;;; If item has been met before, ignore it
unless member(item, donelist) then
;;; remove all occurrences of item
flush(item);
;;; now add it back
add(item);
;;; and remember it
[^item ^^donelist] -> donelist;
endunless;
endfor;
;;; then use the database as the result
database -> newlist;
enddefine;
try it out
prune_list([[a b][c d][a b][d e][c d]]) ==>
prune_list([[x y z][ y z x][a b][c d][a b][x y z][d e][c d]]) ==>
-- Allpresent and which_values ----------------------------------------
Like forevery, the procedure allpresent, and the procedure which_values
are based on the idea of taking several patterns, and looking for
consistent ways of matching them with database items.
But allpresent is more limited in that it finds only ONE such consistent
set of matches, and then stops. E.g.
vars w,x,y,z;
allpresent([[connects ?w ? x] [connects ?x ?y] [connects ?y ?z]]) ==>
them ==>
which_values is sometimes useful when you just want to get the
combinations of values of some of the variables. It must be used with
"!"
which_values(![?x ?z], ![[connects ?x ?y] [connects ?y ?z]]) ==>
Notice that the same pair of values can occur more than once in the
output list. Why?
-- More on the database -----------------------------------------------
An application of the database facilities to a simple simulated world.
TEACH RIVER2
TEACH RIVER2.P
These illustrate the use of the database to store and manipulate a
representation of the world, and also to answer questions.
Procedures to be written include things like the following:
riv_setup(left_things, right_things, boat_things);
riv_whereis(thing) -> place;
riv_can_eat(thing1, thing2) -> boolean;
riv_will_eat(thing1, thing2) -> result;
For reasons explained in TEACH RIVER2 every procedure has been defined
so that it either returns "ok" or a list giving a reason for a negative
answer or a failure to perform. This makes them suitable for use in an
interactive conversational program, unlike LIB RIVER, whose facilities
cause a MISHAP if things go wrong, and a mishap aborts the program.
You don't want that to happen in a conversational program.
It might also be useful in an automatic planning program to have such
procedures which give reasons for their failure, rather than simply
aborting.
Some examples of what will be found in TEACH RIVER2
You can run these examples if you do
lib river2
riv_setup([man fox grain boat], [chicken], []);
database ==>
riv_whereis("man") =>
riv_whereis("chicken") =>
riv_can_eat("fox", "grain") =>
riv_can_eat("chicken", "grain") =>
riv_will_eat("chicken", "grain") =>
The action routines need to check preconditions, and then change
the database as needed:
riv_putin("chicken") =>
Try doing some of the commands twice, or in inappropriate conditions, to
see what happens:
riv_putin("fox") =>
riv_putin("fox") =>
database ==>
riv_getin() =>
riv_getin() =>
riv_putin("fox") =>
riv_takeout("fox") =>
riv_getout() =>
riv_getout() =>
riv_takeout("fox") =>
database ==>
COMPLETE LIST OF RIVER2 PROCEDURES
riv_start()
Set up the initial state of the river.
riv_putin(thing) -> result
Man puts the thing into the boat
riv_takeout(thing) -> result
Man takes the thing out of the boat onto the river bank
riv_getin() -> result
Man gets into the boat
riv_getout() -> result
Man gets out of the boat
riv_cross() -> result
Man rows the boat across the river
riv_eat(thing1, thing2)
Something eats something else. (This produces no result because
its preconditions will always be satisfied when it is invoked.)
-- -- Query procedures
riv_whereis(thing) -> place
riv_is_at(thing, place) -> boolean (true or false result)
riv_is_in(thing1, thing2) -> boolean
riv_will_eat(thing1, thing2) -> boolean
riv_which_at(place) -> list of things
riv_which_in(thing) -> list of things
-- Database reminders -------------------------------------------------
The database package comes with a collection of different facilities:
Look at the uses of
add
addall
remove
flush
present
foreach
forevery
Most of those are illustrated in TEACH RIVER2.
Contrast
present
Takes a pattern and searches for an item in the database, and
stops after finding one. It is a procedure.
foreach
Takes a pattern and matches it against each item in the database
in turn, and performs an action whenever there's a match.
this is a syntax word, with corresponding brackets "do"
and "endforeach"
lvars thing;
foreach ! [at ?thing left] do [^thing is at left] => endforeach;
Contrast
foreach
takes just one pattern
forevery
takes a list of patterns and tries to find consistent ways
of matching them against database items. It is also a
syntax word with "do" and "endforeach" brackets.
Forevery is a very powerful addition, allowing different combinations of
patterns to be matched simultaneously against different items in the
database. This does a form of inference, or reasoning. It is a step
towards the power of prolog.
Here's a simple example: work out which things are at the same place:
vars x, y, place;
forevery [[at ?x ?place][at ?y ?place]] do
if x /= y then
[^x ^y 'are together at' ^place] =>
endif;
endforevery;
Change the database and try the above again:
riv_getin()=>
riv_cross() =>
riv_getout() =>
forevery is a lot more powerful.
-- Next task: build a more convenient interface. See TEACH RIVERCHAT --
Controlling program
define riverchat();
river_start_chat();
river_introduction();
river_converse();
river_farewell();
enddefine;
define river_converse(); ;;; no inputs and no results
lvars input;
repeat
[What next?] =>
readline() -> input;
quitif( input = [bye] ); ;;; stopping condition
river_interpret(input); ;;; still to be defined
endrepeat;
[good bye] =>
enddefine;
Note the use of readline to get information from the user. What
does readline do?
TEACH READLINE
Note that in the editor it suspends the running process till you press
RETURN in the interactive file.
vars list;
'Please type something' =>
readline() -> list;
[why did you say ^^list] =>
To define the interpret procedure you need to think very clearly about
what the Ontology of the domain is, i.e. what kinds of facts can exist,
including what relationships can be talked about. Here are some
examples:
[ the ??obj is ??rel the ??loc ]
the fox is at the left bank
[ where is the ??obj ]
[ what is ??rel the ??loc ]
what is at the right bank
[ is the ??obj ??rel the ??loc ]
is the fox at the right bank
[ put the ??obj ??rel the ??loc ]
put the fox in the boat
And many more. If you can produce a grammar, that is a good way to
generate a very large set of cases in a systematic way, but then you
have to interpret a parse tree
[s [vp
[vnpinnp put]
[np the ... ]
[prep in]
[np the ... ]]]
-- Some examples in the library ---------------------------------------
In an Xterm window try
pop11 +gblocks
It's not easy to make such things work!
TEACH * SCHEMATA
Introduces the task of matching a story (represented as a set of facts
in the database) against a set of scripts or frames to find the "best"
match. This can then be used to predict items of information missing
from the story.
--- $poplocal/local/teach/proglect4
--- Copyright University of Birmingham 2000. All rights reserved. ------