lagache@violet.berkeley.edu (Edouard Lagache) (01/06/88)
I was quite intrigued by Richard A. O'Keefe's comments on the need (or
lack of) string operations in PROLOG. He focused on the question of
concatenation. However, there is a number of basic operations that are
required for decent string handling. As a reference one can take the
"C" string library, which includes (among others):
index = locate a character from the beginning of a string.
strcat = Concatenate two strings.
strcpy = Create a copy of a string.
strcmp = Compare two strings.
strlen = return the length of a string.
"mid$" = Returns a substring between specified intervals (non-
standard, but easily implemented).
I think that some of the above functions do have a place in a
PROLOG predicate library. 'strcmp', for example, is a very useful tool
for making sense of string data, and 'index' and 'mid$' can be used to
get at embedded control characters in strings that represent anything
from device control instructions, to templates for creating pseudo
natural language output.
However, there is a larger issue related to this question. Much
of the work with strings is dumb old procedural operations. Since
procedural operations run counter to PROLOG's way of doing business,
there is an obvious friction involved. There is two ways to resolve
that friction: One way is to try to come up with string primitives that
deal with all the procedural tasks internally and yet represent a
"useful" declarative concept for PROLOG programmer. I suppose that is
what Dr. O'Keefe is seeking, and trying to come up with such primitives
will require much thought and reflection from the PROLOG user
community.
The other approach would be to permit a real dichotomy between
procedural tasks and declarative programming via a second programming
language interface. Several PROLOGs now can call "C" functions, and in
some sense mixing "C" or LISP with PROLOG permits users to have the
best of both worlds.
The risk with that second approach is potential poisoning of the
declarative style of PROLOG with poorly chosen "C" interfaces. Thus,
in some sense we are reduced back the first option. Even if individual
programmers have the freedom to write procedural routines to interface
to PROLOG, those routines must be written to support and enhance the
logical structure of the PROLOG program they are written for.
In that sense PROLOG is a very demanding language, but I suppose
that is where its real power resides.
Edouard Lagache
School of Education
U.C. Berkeley
lagache@violet.berkeley.edu
P.S. I don't know how other PROLOGs are set up with respect to string
and/or atom manipulatives. It may well be the case that most of
my points are mute on the more potent PROLOGs.pds@quintus.UUCP (Peter Schachte) (01/07/88)
In article <6453@jade.BERKELEY.EDU>, lagache@violet.berkeley.edu (Edouard Lagache) writes: > > > I was quite intrigued by Richard A. O'Keefe's comments on the need (or > lack of) string operations in PROLOG. He focused on the question of > concatenation. However, there is a number of basic operations that are > required for decent string handling. As a reference one can take the > "C" string library, which includes (among others): > > index = locate a character from the beginning of a string. > strcat = Concatenate two strings. > strcpy = Create a copy of a string. > strcmp = Compare two strings. > strlen = return the length of a string. > "mid$" = Returns a substring between specified intervals (non- > standard, but easily implemented). Using lists of character codes as strings, strcpy is unnecessary in Prolog (it is never necessary to copy a ground term). Given that, all of the above mentioned operations, except for strcmp, can be defined as non-recursive Prolog predicates in terms of append/3 and length/2 (length/2 must be able generate a list given its length, as well as calculate the length of a given list). And strcmp isn't hard to write as a recursive predicate. The point of this is that string manipulation is something done quite easily in Prolog, and reasonably comfortably within the bounds of logic. They DON'T have to be thought of as procedural operations, and shouldn't. Richard's point is also that handling them as lists is quite efficient enough for most applications, and that in fact it is often MORE efficient than more traditional representations (arrays). > [ Lagache argues that procedural operations are needed in Prolog, and > should be supplied either as primitives, carefully packaged to look > as relational as possible (for example name/2), or by supplying an > interface to procedural languages. He worries that "The risk with > that second approach is potential poisoning of the declarative style > of PROLOG with poorly chosen 'C' interfaces." ] But Prolog has always had procedural primitives; for example, write/1. It MUST have them. You must have side-effects, or you can't print out the results of your computation. It's a matter of practicality. The trick is to circumscribe the procedural parts of your program, and keep the logical part pure. It's not really possible to shield the programmer from having to think about side-effects sometimes. And there are bound to be primitives that the implementor of the Prolog system just didn't think of, so supplying an interface to a systems programming language provides access to whatever operations the the system programmer can supply, e.g., system-dependent file system operations. But it must be the Prolog programmer's job to use these facilities thoughtfully. I speak for myself. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds