Copy Link
Add to Bookmark
Report
AIList Digest Volume 4 Issue 124
AIList Digest Tuesday, 20 May 1986 Volume 4 : Issue 124
Today's Topics:
Queries - Expert Systems for Theoretical Mathematics &
Logic/Functional Languages & VAX VMS Lisp & Bray Reference,
AI Tools - Common LISP Style & Prolog for AI Book & Turbo Prolog
----------------------------------------------------------------------
Date: 14 May 86 04:34:51 GMT
From: ihnp4!alberta!sask!kusalik@ucbvax.berkeley.edu (Tony Kusalik)
Subject: Expert Systems (info wanted)
I am looking for any pointers/info on
past/existing/prospective expert systems
for theoretical mathematics written in Prolog
or other languages based on logical inference.
thanks.
Tony Kusalik
kusalik@sask.bitnet
...!{ihnp4,ubc-vision,alberta}!sask!kimnovax!kusalik
------------------------------
Date: Thu, 15 May 86 21:14 EDT
From: Paul Fishwick <Fishwick%upenn.csnet@CSNET-RELAY.ARPA>
Subject: Logic/Functional Languages?
Does anyone on the list know of available languages incorporating both
logic and functional programming (preferably in a Unix 4.2 environment
or possibly an IBM/PC)? Specifically, I'm looking for one or both
of the following:
1) Some version of Prolog embedded within Common Lisp (I've heard of
LISPLOG or POPLOG - anyone have any experience with these?). A
set of add-on macros or function library to an already extant
lisp would be best.
2) Any of the systems discussed in the book "Logic Programming -
Functions, Relations, and Equations" by DeGroot & Lindstrom.
Has anyone produced any large applications with these hybrid systems?
Are the benefits derived from the systems *significant* (over using, say,
vanilla lisp or prolog)? If I get enough replies, I will post a summary
of names and addresses where these languages can be obtained...Thanks.
-paul
------------------------------
Date: Thu, 15 May 86 18:27:04 PDT
From: larry@Jpl-VLSI.ARPA
Subject: VAX VMS LisP
Are there any Common LisPs for the VAX under VMS? (DEC's VAX LisP is an
Ultrix product only, so far as I know.)
If there's no (decent) Common LisP, what is the best choice?
Larry @ jpl-vlsi.arpa
------------------------------
Date: 16 May 86 15:09:44 PDT (Friday)
From: Hoffman.es@Xerox.COM
Subject: Bray reference
I'm looking for more details on one reference in the recent
bibliographies. I didn't save them, so here is my own version:
Bray, M. and G. Schmidt (editors), 'Proceedings of NATO
Summer School on Theoretical Foundations of Programming
Methodology', Dordrecht: Riedel (1982).
With just this much, librarians can't seem to find any listing for it.
Can anyone supply more information?
Thanks,
--Rodney Hoffman
------------------------------
Date: 14 May 86 00:59:00 GMT
From: pur-ee!uiucdcs!uiucdcsp!bsmith@ucbvax.berkeley.edu
Subject: Re: Common LISP style standards.
A couple of short comments.
First, about comments. You might want to embed into a function
a string that will print out as on the fly documentation if the system
supports it (Symbolics does). This helps when using a function you wrote
2 months earlier that's lost somewhere in 200 pages of code.
Second, there are a couple of rules about using conditionals that
make a lot of sense. If you have a single condition followed by a single
then statement followed by a single else statement, use "if." If you have
a single condition followed by a single then statement and no else
statement, use "when." If you have a single negative condition followed
by a single then statement, use "unless." If you have multiple conditions,
or need to use progn anywhere, a cond is more readable.
------------------------------
Date: 16 May 86 19:27:00 GMT
From: pur-ee!uiucdcs!uiucdcsb!mozetic@ucbvax.berkeley.edu
Subject: New book: Prolog for AI
Addison-Wesley published a new book:
PROLOG Programming for Artificial Intelligence by Ivan Bratko
The first part introduces Prolog and shows how Prolog programs
are developed.
The second part applies Prolog to some central areas of AI, and
introduces fundamental AI techniques through complete Prolog
programs. Throughout the book there is a lot of exercies and
sample programs. The following is a table of contents:
THE PROLOG LANGUAGE
1. An Overview of Prolog
2. Syntax and Meaning of Prolog Programs
3. Lists, Operators, Arithmetic
4. Using Structures: Example Programs
5. Controlling Backtracking
6. Input and Output
7. More Built-in Procedures
8. Programming Style and Technique
PROLOG IN ARTIFICIAL INTELLIGENCE
9. Operations on Data Structures
10. Advanced Tree Representations
11. Basic Problem-Solving Strategies
12. Best-first: A Heuristic Search Principle
13. Problem Reduction and AND/OR Graphs
14. Expert Systems
15. Game Playing
16. Pattern-Directed Programming
------------------------------
Date: Tue, 13 May 86 00:49:19 PDT
From: newton@vlsi.caltech.edu (Mike Newton)
Subject: Review of Turbo-Prolog
[This is a review of Turbo Prolog. I have *not* read all of the
manual, nor used it on many programs. Views expressed are from the
perspective of someone who has done the code generation and
evaluatable predicates for a high speed (810 KLips on one processor
of a IBM 3090) prolog compiler. I have no affiliation with
Borland, and only a (*very*) indirect affiliation with IBM -- MON]
>From a local software store we purchased Turbo Prolog over the weekend.
It came as a cellophane wrapped book with a couple of floppies. It cost
$69.95, list of $99.
The enviromnent was very nice. There was a window for the editor, goals
debugging information and messages. This seemed well done, and responded
reasonably well (I am not used to IBM-PC's.)
The unfortunate part was the Pascal-ization of the language. Everything
had to be typed (they called it domains). As far as I could tell, lists
had to be composed solely of other lists or elements all of one type. One
had to define the possible terms (giving the functor) that could be
arguments to a predicate. It seemed impossible to write generic predicates
for dealing with arbitrary types of terms.
Ex: to have a term that could be a 'symbol' (atom) or an integer
one had to do this:
domains
aori = a(atom) or i(integer)
It was not possible to just use an atom or an integer as a subterm...
Typing each subterm of a term is not my idea of Prolog.
After about an hour we got the 'standard' timing example of naive
reverse running (Some people have used other, non-environment-creating
samples. This is an unfair comparison). It did 496 unifications in
aproximately 11/100 of a second. This amounts to a speed of a little
under 5 Klips. Considering that they do not need to do 'real' unification
(since everything is pre-typed, and thus can be reduced to a simple test),
this speed is not particularly impressive.
- mike
newton@cit-vax.caltech.edu {ucbvax!cithep,amdahl}!cit-vax!newton
Caltech 256-80 818-356-6771 (afternoons,nights)
Pasadena CA 91125 Beach Bums Anonymous, Pasadena President
------------------------------
Date: 16 May 86 09:24:00 EST
From: "CUGINI, JOHN" <cugini@nbs-vms.ARPA>
Reply-to: "CUGINI, JOHN" <cugini@nbs-vms.ARPA>
Subject: Preliminary notes on Turbo Prolog
Quickie Review of Turbo Prolog
This is a rough set of notes about Turbo Prolog (hereafter TP).
It is a *linguistic* comparison of TP vs. the Clocksin & Mellish
book (CM) and Pereira's CProlog (CP). It is based mostly on a
reading of the TP manual, not live experimentation with the
product itself. There is no evaluation of performance, nor much
of the programming environment provided by TP.
TP is related to, but by no means compatible with, either CM or CP.
In the list below, I've put TP/CP differences first, and then
TP enhancements.
1. Declarations.
Structures must have the types of their arguments declared. That
is, you can't just toss in compound terms in facts and rules.
The functors for all predicates must be declared, together with
role names for each of the arguments, in a PREDICATES section,
like this:
predicates
person(name, height, weight, hair_color)
name2(last, first)
name3(last, first, middle)
and each role must declare from which domain(s) it is drawn,
in a DOMAINS section (which must precede the predicates section);
very relational databasy:
domains
name = name2(last, first); name3(last, first, middle)
/* name is either a name2 or name3 structure. */
first, middle, last = symbol
/* first, middle, and last are all (atomic) symbols. */
height = integer
weight = real
hair_color = symbol
What's normally thought of as the regular program is contained
in a CLAUSES section, following the two above.
There are five primitive atomic data types (integer, real, char,
string, symbol), and everything is built from these.
A given domain may consist of a single primitive type or a
disjunction of compound types, but *not* a disjunction of
primitive types. Since lists are declared like this:
numlist = integer* /* numlist is a list of integers */
it appears that lists must be relatively homogeneous, ie,
must contain elements of either a single primitive type, or
a few compound types. The whole flavor is much more that of
compilation, data definition, Pascal, and type-checking, than of
the usual interpreted, free-spirited CP or CM. Thus TP stresses
documentation, security, and efficiency, but disables some
dynamic data building features.
2. Declaring the use of Arguments.
When an argument may be passed unbound from one sub-goal to
another, it must be declared as a *reference* whatever, back up
in the domain declarations to tell TP to pass it be reference,
since TP otherwise assumes it can be passed by value (i.e.
already instantiated), eg:
domains
height = reference integer /* height is a pointer to an integer */
tree = reference node(integer, tree, tree)
/* note recursive structure */
3. No meta-logical probing of the DB.
There is nothing like CP's predicates: =.., functor, arg,
clause, or current_functor for fiddling with the current
program's clauses. In general, there's is no run-time
inspection or building of rules. Assert and retract work
only for facts.
4. There are no user-defined operators, nor CP's expand_term
for pre-processing.
5. Syntax shuffling -
TP CP
--------- --------
bound, free nonvar, var
< @< /* for strings and symbols */
= is /* numeric computation */
= =:= /* numeric test */
equal = /* term unification */
bitand, bitor /\, \/
bitnot \
bitleft, bitright <<, >>
Also, all rules for the same predicate must be lexically
contiguous, and you can use the keywords "and", "or", and "if"
instead of the symbols ",", ";", and ":-".
6. TP implements CM's findall, rather than CP's setof and bagof.
7. TP has lots of features for handling files and I/O.
Its predicates for input (read_x), however, expect to know
the type of object, eg, readint, readreal. TP doesn't have
CP's get for single character input. It does have readln
to read an entire line into a string.
8. TP has goodies to handle (fixed-format) databases on
disk. Eg, dbassert/dbretract add/delete facts to/from
an external (permanent) database.
9. TP has features for program modularization. Each module
can be compiled independently, and has its own name space,
eg, for domains and predicates. There is also a way to set up
global domains and predicates visible to all modules.
10. TP handles character-strings as a full-fledged data-type.
Also it has functions for conversion among the primitive types.
11. TP has predicates to control graphics, windows, sound, etc.
12. The TP editor is Wordstar-like, not especially Prolog-oriented.
The opinions expressed herein have been officially approved and
sanctioned by the Supreme Court, both houses of Congress,...
no, no, only kidding, only kidding, actually I didn't even
consult with them - please don't blame anyone but me.
John Cugini <Cugini@NBS-VMS>
Institute for Computer Sciences and Technology
National Bureau of Standards
------------------------------
End of AIList Digest
********************
