PROLOG-REQUEST@SUSHI.STANFORD.EDU (Chuck Restivo, The Moderator) (03/16/87)
PROLOG Digest Monday, 16 Mar 1987 Volume 5 : Issue 16
Today's Topics:
Query - Translation & External Calls,
Implementation - Turbo,
Announcement - New Series
----------------------------------------------------------------------
Date: 11 Mar 87 16:31:36 GMT
From: John Dowding <sdcrdcf!burdvax!bigburd!dowding@hplabs.hp.com>
Subject: Translating into Prolog
Does anyone out there have experience with implementing very high
level languages in Prolog? I have been working on a translator for
the Restriction Grammar (a logic grammar formalism). My problem is
that the resulting Prolog code contains extremely large data
structures, much larger than you would find in a program written in
Prolog directly.
My understanding is that most Prolog compilers are optimized to make
handling small terms efficient at the expense of large terms (by using
copy-on-use rather than structure-sharing). Does anyone know of any
methods to use in translation to make large terms efficient?
Thank you.
-- John Dowding
------------------------------
Date: 12 Mar 87 07:37:00 EST
From: John Cugini <cugini@icst-ecf>
Subject: External calls from Vax C-Prolog
Does anyone have any advice and/or code for making external calls from
C-Prolog running under VAX/VMS to other languages? For example,
ForTran. Ideally, I'd like to do something like:
Prolog:
...
ext_call(foo(2, 3.3, "gsgs", Ans1, Ans2)),
...
Fortran:
subroutine foo (ival, rval, cval, ans1, ans2)
character cval*4 ....
with the obvious (?) semantics (i.e., all side-effects, such as
printing, would occur, and Ans1 and Ans2 would be instantiated). It
would also be nice to be able to control whether this succeeds
repeatedly, or fails after the first attempt, etc.
-- John Cugini
------------------------------
Date: Fri, 13 Mar 87 11:24:56 PST
From: Fernando Pereira <pereira@sri-candide.ARPA>
Subject: Further Turbo clarification
Since it might not be very clear from my latest message, Mike Newton's
review of Turbo Prolog, attributing to me the eq(X,X) observation, was
based on an early version of Turbo -- in fact my own comment was based
on trying out the Danish system that saw the light in the US as Turbo
Prolog. My comment was correct re. that early version, which did not
allow the ``reference'' types. The latest version, as Steve Hardy and
Chris Moss pointed out, allows those declarations. Still, even with
reference types, Turbo Prolog seems to be restricted to programs in
which argument passing is ``noncircular'' in the attribute grammar
sense. When I get some time and access to the latest Turbo, I'll
elaborate on this point.
-- F
------------------------------
Date: Thu, 12 Mar 87 10:26:06 MST
From: ted%nmsu.csnet@RELAY.CS.NET
Subject: Question regarding Turbo Prolog
One of the most important techniques in advanced programming is higher
order programming. This means that the generic aspects of a procedure
are ``factored'' out and some sort of functional entity is used as a
parameter to allow the general procedure to function in a specific
application. For instance, map from LISP, or apply-to-all from fp
express the generic operation of applying some function to a list of
operands. A particular use of map might specify that all of the
elements of a list should be squared, in which case the function
passed to map would be a function to square a number.
The capabilities that are required to reasonably write and use
higher-order functions (procedures, predicates...) is that there
is a convenient way to describe variables of type function in the
definition of the higher-order function and constants of the type
function in the call to the higher order procedure. It is nice
to be able to more general things with functions besides
describing constants and applying them to arguments but there are
still a number of difficult issues to do with compilation,
interpretation and whether the final program will have the
capability to compile or interpret general language structures.
A second very powerful technique is that of program
transformation. If the base language that you are using does not
easily express your program, it may be that there is a simple
transformation that would allow you to write a program in a lucid
way and have it compiled to your base language. In LISP systems,
this technique is available in a limited form by using reader
macros, macros and special forms. In most Prolog's this
technique is used to implement definite clause grammars, and in
conventional settings it has been used to preprocess out the
rough spots in available languages. Examples of this include
RATFOR (which made fortran almost palatable), C (the preprocessor
is built in), and C++ (where a preprocessor converts object
oriented programs to conventional C).
The difficulty of implementing preprocessors for conventional
languages on the level of bits, bytes, characters and symbol
tables is considerable. In most symbolic languages, though, the
basic syntactic forms of the language can be read as data
structures which are really parse trees of the original syntactic
forms. This allows the writer to concentrate on the
transformation and not the parsing.
Turbo-Prolog is severely lacking in the above areas since
a) it is impossible to declare a data type which can be
used to write terms in the same format as normal Prolog
terms. This means that you cannot pass general predicate
calls to higher order procedure. It is impossible to
write findall from C+M without writing an entire Prolog
interpreter and writing the calls to findall in a stilted
non-prolog syntax.
b) it is impossible to directly call a general predicate
even if you declare a limited type which would handle a
limited number of terms. This limitation is above and
beyond that implied by a.
c) the typing system implicitly prevents one from using
structures which directly correspond to program
structures. This lack is reflected in the fact that read
is broken into several type specific predicates in
Turbo-Prolog. Without being able to manipulate program
structures directly, the programs written to do program
transformation become exceedingly dense.
d) without the ability to read general terms directly,
the programmer wishing to rectify the deficiencies of
prolog must write a complete parser. This alone nearly
negates the purported advantage of being able to
manipulate program structures.
The declaration of new operators in Prolog is closely allied with
the ability to clearly express programs and data structures with
clear and novel syntax. Without a general read and without
general terms, this capability loses its meaning anyway, and
turbo-prolog is consistent in disallowing this capability.
In summary, Turbo-Prolog is not useable for the advanced programmer
since higher order functions cannot be efficient and clearly be
implemented, nor can program transformations be easily
implemented.
The first warning of these lacks is the exclusion of all the
predicates which are normally used to manipulate terms and
structures. The root of the elimination of =.., functor, clause
and arg is the same as the root of Turbo-Prologs incapacity for
advanced programming.
------------------------------
Date: 18 Feb 87 14:16:51 GMT
From: Keith Clark <mcvax!ukc!icdoc!klc@seismo.css.gov>
Subject: PARLOG book launches new series
International Series on Logic Programming
-----------------------------------------
Publisher: Addison-Wesley
Series editor: Keith Clark, Imperial College
Associate Editors: Bob Kowalski, Imperial College
Jean-Louis Lassez, IBM Yorktown Heights
Editorial Board: K. Furukawa (ICOT, Japan)
H. Gallaire (ECRC, Munich, FRG)
J.W. Lloyd (University of Melbourne, Australia)
J. Minker (University of Maryland, USA)
J.A. Robinson (Syracuse University, USA)
S-A. Tarnlund (Uppsala University, Sweden)
M.H. van Emden (University of Waterloo, Canada)
D.H.D. Warren (Manchester University, England)
The first book in the series:
PARALLEL LOGIC PROGRAMMING IN PARLOG
the Language and its Implementation
by
Steve Gregory
has now been published in the UK, and should be available elsewhere
by April, 1987.
Three or four other books are currently under consideration. The
emphasis will be on quality rather than quantity, so that publication
in the series is a mark of esteem.
If you have an idea for a book, or better still a draft on any topic
under the Logic Programming umbrella, please contact Keith Clark, at
klc@doc.ic.ac.uk.
------------------------------
End of PROLOG Digest
********************