Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.lang.prolog
Subject: Re: String operations in PROLOG: some comments.
Message-ID: <509@cresswell.quintus.UUCP>
Date: 6 Jan 88 19:13:21 GMT
References: <6453@jade.BERKELEY.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 57
Keywords: "C" interfaces, declarative vs procedural programming
Summary: Prolog already HAS procedural operations built in.

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