Path: utzoo!mnetor!uunet!husc6!ncar!ames!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Strings
Message-ID: <821@cresswell.quintus.UUCP>
Date: 26 Mar 88 06:12:05 GMT
References: <241@gould.doc.ic.ac.uk>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 134

In article <241@gould.doc.ic.ac.uk>, cdsm@doc.ic.ac.uk (Chris Moss) writes:
> Now here's an odd thing: there is no writestring routine in the Quintus
> library that I can discover! Not in the built-ins or the (extensive)
> library!  

There are two separate and distinct ways of doing this using the
Quintus library, and both are documented in the Library manual.

In Section 8.3, you will find

	put_chars(+Chars)
and
	put_line(+Chars)

described.

These are exactly the writestring you want, except that they have
truthful names.  (put_chars/1 does 'put' to a 'chars', that is, to a
list of 'char's.  put_line does 'put' to a list of character codes
considered as a line; it's the equivalent of puts(3S) in the C library.)

There is also a library package called library(print_chars) which
makes the 'print'ing of chars values entirely automatic.  It is
described in section 9-2-2 of the library manual.  The point of this
is that once you have done

	| ?- ensure_loaded(library(print_chars)).

then top-level output, debugger output, and print/1 will have this sort
of effect:

	| ?- X = ["this","is","a","list","of","chars","values"].
	X = ["this","is","a","list","of","chars","values"]

	| ?- append("stuff", Tail, Chars).
	Tail = _537,
	Chars = "stuff|Tail"

{this is an excerpt from an actual transcript}.  If you look in the
DEC-10 Prolog library you will find the ancestor of print_chars under
the name PORSTR.PL.

> What does that tell us about the use of strings? It suggests to
> me that people actually always use atoms for this purpose, and somewhere 
> in their code is an implicit definition: 
>     writestring(String) :- name(Atom,String),write(Atom).  

What it actually tells us is that Chris Moss didn't look very hard in
the manual.  Even if the Quintus library didn't provide two ways of
doing this, what people have done in other dialects is to define

	puts([]).
	puts([C|Cs]) :- put(C), puts(Cs).

In fact, if I remember correctly, MU-Prolog extended put/1 to do this.
Why drag atoms into it?  In fact, the code that Chris Moss shows us will
not work:  writestring("00") would print a single "0".  {Yes, this is not
a nice thing for name/2 to do, which is why Quintus Prolog offers
atom_chars/2 _as well_.}

> 2. I don't like having ASCII values in my programs.

As Chris Moss explained later in his posting, this is not an argument AGAINST
having a notation for lists of character codes.  It is an argument FOR having
a notation for character constants.

> With a certain amount
> of discipline and inefficiency one can get round that, by saying, for 
> instance:
>     lowercase(X) :- "a"=[A], "z"=[Z], X>=A, X=<Z.

Why do that when you can write
	lowercase(X) :- "a" =< X, X =< "z".
Better yet, why not do
	lower_case(X) :- is_lower(X).
where is_lower/1 is one of the character classification predicates stolen
from C that I suggested in my 1984 "evaluable predicates" document (BSI
number PS/6).  (Quintus Prolog provides this, and NU Prolog provides it
under the name isLower/1.)  Best of all, is_lower/1 will solve for X...

In fact, while Chris Moss may not _like_ having ASCII values in his
programs, that's what he just did, and having a character type won't
make them go away.  His code for lowercase is quite wrong for EBCDIC.
It's also wrong for ISO 8859, where there are another 64 lower case
letters.  The Quintus Prolog library contains a package ctypes.pl which
comes in an EBCDIC version as well as an ASCII version, and
	is_lower(X)
is the right thing to do in either context.

This is part of what I meant in an earlier posting by asking what was the
right set of operations for a character type.  (How do you test whether a
character code stands for a Hebrew letter in the appropriate variant of
EBCDIC?  No fair looking in the 3270 manual, now.)

> OK, there is the 0'a notation (another way of writing 97 if you're using
> ASCII). Now that DOESN'T work in MuProlog, or Poplog or ...

It _DOES_ work in NU Prolog, the successor to MU Prolog.  (See section
3.2.2 paragraph (c) of the NU Prolog manual, version 1.1.)  And PopLog
has `a`, has it not?  It should be the work of a few minutes to convert
0'a to `a` or conversely by writing a VED or EMACS macro.

> On efficiency I mostly agree with Richard. I too like strings to be lists,
> and can't see the real benefits of a string type, though you don't tend to
> miss what you never had!

Try SNOBOL, PL/I, BASIC, Burroughs Extended Algol, AWK, Common Lisp, &c &c.
What a pain what a pain.

> As far as notation is concerned I have no better suggestion
> than 0'a though I don't much like it.

The reason that Edinburgh Prolog uses 0'x is that by the time we thought
of it, there were programs using all the other ASCII printing characters,
and the DEC-10 tokeniser already accepted 0'<digits> but didn't do anything
terribly sensible with it.  The only virtue I've ever claimed for it is
that it didn't break anything.  The Pop-11 `x` notation is obviously
superior as a notation.  (0'x also suggests, as it is meant to, that it
is an integer.  `x` doesn't suggest that, so would be more appropriate to
a separate "character" type.).

> I wouldn't object to the C solution, which allows them to be used 
> in arithmetic contexts. e.g. Num is Ch-0'0 or Letter =<0'z.

But the C solution is that characters *ARE* integers.
The constant expression 'a' in C has type "int", not "char".

> Most of my suggestions at main committee meetings have been ignored!

I'm very sorry to hear that, but the quality of the BSI built-in-predicates
work seemed to me to be far too low to be compatible with the assumption that
you had much of a hand in it.  This is not to say that I would expect to
_like_ your suggestions if I knew what they were, but I certainly would
expect them to be coherent and sensible.