🚀 go-pugleaf

     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.