From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=3.0 tests=BAYES_00,FROM_NO_USER
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: Mon, 23 Nov 92 11:27:27 CST
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Computer languages
Message-ID: <9211231727.AA13389@efftoo.boeing.com>
List-Id: <comp.lang.ada>

cochiti.lanl.gov!jlg@lanl.gov  (J. Giles) says:

>C has *NO* language features supporting text *at all*.

Sorry.  I should have said "C and Unix".  Take one example: strtok().
I use this all the time to parse command lines or other free-form
inputs.  Then there are the macros islower and toupper, and on and on.

I fear I have trod on religious ground again.  Look, Ada has a model
of a string as an array, one of whose attributes is length.  I do
believe that there's power in "array (Positive range <>) of Character".
It's marvelously abstract, and you get the size of the string for free
without having to resort to strlen(), for example.

But I also think that there's power in C's model: a null-terminated
array of char.  Let's take an example: you have two processes which
intercommunicate outside Ada's context (how many non-proprietary
multi-CPU Adas do *you* know about?).  So the Ada process either looks
at some region of shared memory or it reads from a stream.

So the writing process has to jot down both the string itself and
the length of the string.  Minimal problem: you have to write two
things instead of one (though we certainly sacrifice some abstraction
by having to peek under the hood to pass an attribute).  The reading
process, on the other hand, is worse off.  It has to use NEW (and a
copy) to get ahold of that string and do anything with it.  Come to
think of it, I've had to use NEW for strings in subprograms *within*
the Ada context because of some bitchy string "feature" or other.

A C process, on the other hand, simply assumes that the string is
terminated by a null and can deal with the string in situ.

I am aware of the Verdix C_Strings and A_Strings packages as well as
the stuff that sommar@enea.se was kind enough to email me.  These
utilities generally permit you (require you?) to convert from Ada's
built-in string type to some other string type.  But that makes
my point again, doesn't it?:  For some purposes, Ada's model of strings
is less useful than other models.

If you have a program whose chief activity is to manipulate C strings or
which takes advantage of all the Unix/C library string manipulation
functions, then I believe that writing such a program in Ada, converting
from Ada strings to C strings and back again, is an exercise in silliness.
If, on the other hand, you have to convert between strings and enumerations,
or if the string manipulation is only a small part of the functionality
of the program, then there's no place like Ada.

>>From time to time we're required to be silly; other times we're silly
through inadvertence; let's not be silly deliberately!

>Fortran has string assignment, substring selection, and concatenation
>*built-in*!

Well, your experience must certainly be different from mine.  I had a
set of text manipulation programs to write in Fortran several years
ago and found the (Gould) Fortran string manipulation operations so
slow and so buggy that I ended up EQUIVALENCEing a bunch of arrays of
INTEGER*1, INTEGER*2, INTEGER*4 and INTEGER*8s and dealing with all my
strings as integers.  Scarcely an advantage for this particular Fortran!
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+