Path: utzoo!mnetor!uunet!mcvax!ukc!eagle!icdoc!doc.ic.ac.uk!cdsm
From: cdsm@doc.ic.ac.uk (Chris Moss)
Newsgroups: comp.lang.prolog
Subject: re: Strings
Message-ID: <241@gould.doc.ic.ac.uk>
Date: 24 Mar 88 18:35:05 GMT
Sender: news@doc.ic.ac.uk
Reply-To: cdsm@doc.ic.ac.uk (Chris Moss)
Organization: Dept. of Computing, Imperial College, London, UK.
Lines: 78

I haven't contributed to the string discussion because I don't believe I
know all the answers. But I do have strong reservations about the current
Edinburgh implementations. Let me air them:

1. They don't get printed properly by "write". I don't like seeing
"Prolog" come out as [80,114,111,108,111,103]. OK, I can define a
"writestring", but not use it within a bigger structure without pain.  

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!  

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).  

Note that in most systems this involves an entry in the symbol table 
(reasonably slow) and a limit of 256 (or maybe 512) characters.

MuProlog DOES print out "Prolog" as a string, wherever it occurs.
Presumably it has to scan the list first. It uses list format whenever
there is a integer outside the range 32-127 in the list (it also gets tabs
right tho I don't understand why it finishes at 127 not 126). That's a
pretty good heuristic, tho I can imagine it going wrong on occasions. e.g.
if I read in a clause over several lines the string will contain newlines,
so my DCG debugging will still look horrid!

2. I don't like having ASCII values in my programs. 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.
but it's not an ideal solution (tho close to normal arithmetic habits in
Prolog). These type of routines tend to be efficiency sensitive. 

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 ...

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!

So, what I would like to see is not a string type but a CHARACTER type. 
Small integers work in Ed-Prolog mainly because they're efficient for get
and put -- there's no symbol table lookup. It would be nice to treat
single character atoms as their ASCII value, but that's wrong because one
does want to hang things off atoms. So they would have to be a separate
data type. As far as notation is concerned I have no better suggestion
than 0'a tho I don't much like it.

Now I don't object to Pascal's ORD (tho Modula II's ORD is TERRIBLE.
It is defined as CARDINAL so one usually has to say VAL(INTEGER,ORD("a"))).
But one-way transfers aren't much of a problem semantically, so 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.

Thus the main difference with the present systems would be:
  1. 0'a wouldn't unify with 97. (I assume)
  2. write(0'a) would print out 0'a.
  3. write("abc") or write([0'a,0'b,0'c])  would print out as "abc".
  4. One would need a "CHR" function (but not ORD) in arithmetic
expressions.

The question is, "is it worth the change"?  For my pennyworth the answer
is "yes". NOT having a character type makes Prolog as archaic as Fortran
IV in computer-science terms. I don't much like the string type idea. And
if you say "you proposed it" you're wrong. I've only been concerned with
syntax and semantics, not the built-in-predicates (there are limits to the
number of committees any sane person can attend!). Strings have been mostly
discussed in the BIPs meetings. Most of my suggestions at main committee
meetings have been ignored! When it comes to the semantics one needs a
character type even in the present proposal.

The biggest anti-argument is that all sorts of Prolog programs might break
in weird ways because of difference 1. I don't know the answer to that.

Chris Moss