The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Dan Stromberg <drsalists@gmail.com>
Cc: The Unix Heritage Society mailing list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view)
Date: Mon, 5 Jul 2021 17:29:02 -0400	[thread overview]
Message-ID: <CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com> (raw)
In-Reply-To: <CAGGBd_r-nhpbWGaHAxo+7sRf8VPLMiRx5oQK-Cz_kkm0Y=8JPg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5336 bytes --]

On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg <drsalists@gmail.com> wrote:

> A null-terminated array of char is a petri dish.  A proper string type is
> more like a disinfectant.
>
Hrrmpt.... maybe (in theory), but I can say that never seen it really work
in practice --  bwk in Why Pascal is Not My Favorite Programming Language
<http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much of the
practical realities of this sort of choice:

2.1.  The size of an array is part of its typeIf one declares

     var     arr10 : array [1..10] of integer;
             arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively.  Suppose
we want to write a procedure 'sort' to sort an integer array.  Because
arr10 and arr20 have different types, it is not possible to write a single
procedure that will sort them both.

The place where this affects Software Tools particularly, and I think
programs in general, is that it makes it difficult indeed to create a
library of routines for doing common, general-purpose operations like
sorting.

The particular data type most often affected is 'array of char', for in
Pascal a string is an array of characters.  Consider writing a function
'index(s,c)' that will return the position in the string s where the
character c first occurs, or zero if it does not.  The problem is how to
handle the string argument of 'index'.  The calls 'index('hello',c)' and '
index('goodbye',c)' cannot both be legal, since the strings have different
lengths.  (I pass over the question of how the end of a constant string
like 'hello' can be detected, because it can't.) The next try is

     var     temp : array [1..10] of char;
     temp := 'hello';

     n := index(temp,c);

but the assignment to 'temp' is illegal because 'hello' and 'temp' are of
different lengths.

The only escape from this infinite regress is to define a family of
routines with a member for each possible string size, or to make all
strings (including constant strings like 'define' ) of the same length.

The latter approach is the lesser of two great evils.  In 'Tools', a type
called 'string' is declared as

     type    string = array [1..MAXSTR] of char;

where the constant 'MAXSTR' is ``big enough,'' and all strings in all
programs are exactly this size.  This is far from ideal, although it made
it possible to get the programs running.  It does not solve the problem of
creating true libraries of useful routines.

There are some situations where it is simply not acceptable to use the
fixed-size array representation.  For example, the 'Tools' program to sort
lines of text operates by filling up memory with as many lines as will fit;
its running time depends strongly on how full the memory can be packed.

Thus for 'sort', another representation is used, a long array of characters
and a set of indices into this array:

     type    charbuf = array [1..MAXBUF] of char;
             charindex = array [1..MAXINDEX] of 0..MAXBUF;

But the procedures and functions written to process the fixed-length
representation cannot be used with the variable-length form; an entirely
new set of routines is needed to copy and compare strings in this
representation.  In Fortran or C the same functions could be used for both.

As suggested above, a constant string is written as

     'this is a string'

and has the type 'packed array [1..n] of char', where n is the length.  Thus
each string literal of different length has a different type.  The only way
to write a routine that will print a message and clean up is to pad all
messages out to the same maximum length:

     error('short message                    ');
     error('this is a somewhat longer message');

Many commercial Pascal compilers provide a 'string' data type that
explicitly avoids the problem; 'string's are all taken to be the same type
regardless of size.  This solves the problem for this single data type, but
no other.  It also fails to solve secondary problems like computing the
length of a constant string; another built-in function is the usual
solution.

Pascal enthusiasts often claim that to cope with the array-size problem one
merely has to copy some library routine and fill in the parameters for the
program at hand, but the defense sounds weak at best:(12
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-12>)

``Since the bounds of an array are part of its type (or, more exactly, of
the type of its indexes), it is impossible to define a procedure or
function which applies to arrays with differing bounds.  Although this
restriction may appear to be a severe one, the experiences we have had with
Pascal tend to show that it tends to occur very infrequently.  [...]
However, the need to bind the size of parametric arrays is a serious defect
in connection with the use of program libraries.''

This botch is the biggest single problem with Pascal.  I believe that if it
could be fixed, the language would be an order of magnitude more usable.  The
proposed ISO standard for Pascal(13
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-13>) provides such a
fix (``conformant array schemas''), but the acceptance of this part of the
standard is apparently still in doubt.
ᐧ

[-- Attachment #2: Type: text/html, Size: 10704 bytes --]

  parent reply	other threads:[~2021-07-05 21:30 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 21:24 [TUHS] [tuhs] The Unix shell: a 50-year view Nelson H. F. Beebe
2021-07-02 21:36 ` Larry McVoy
2021-07-02 21:56   ` Henry Bent
2021-07-02 23:12     ` Steve Nickolas
2021-07-02 23:49       ` Steffen Nurpmeso
2021-07-03 13:34         ` Steffen Nurpmeso
2021-07-03 13:56           ` Richard Salz
2021-07-03 12:04       ` Thomas Paulsen
2021-07-03 13:20         ` Dan Cross
2021-07-03 17:37           ` Theodore Ts'o
2021-07-03 17:57             ` Warner Losh
2021-07-03 18:10               ` Theodore Ts'o
2021-07-03 20:02                 ` Dan Cross
2021-07-04  0:47           ` Tomasz Rola
2021-07-04  4:36             ` Larry McVoy
2021-07-04 14:56               ` Dan Cross
2021-07-04 16:07               ` Theodore Ts'o
2021-07-04 20:10               ` David Barto
2021-07-05  0:25                 ` Larry McVoy
2021-07-05  1:23                 ` John Cowan
2021-07-04 12:48             ` Dan Cross
2021-07-05  7:14               ` Tomasz Rola
2021-07-05 16:26                 ` John Cowan
2021-07-06 23:17                   ` Tomasz Rola
2021-07-06 23:47                     ` Steve Nickolas
2021-07-06 23:49                       ` Warner Losh
2021-07-06 23:48                     ` John Cowan
2021-07-07  0:46                     ` Theodore Ts'o
2021-07-07  0:58                       ` George Michaelson
2021-07-07  2:48                         ` Larry McVoy
2021-07-07 18:32                       ` Tomasz Rola
2021-07-07 20:50                         ` Michael Kjörling
2021-07-08  6:46                           ` [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view) Tomasz Rola
2021-07-08 13:59                             ` Derek Fawcus
2021-07-08 19:25                               ` Steffen Nurpmeso
2021-07-08 19:37                                 ` Steffen Nurpmeso
2021-07-08 20:40                                 ` Steffen Nurpmeso
2021-07-08 22:23                             ` Kevin Bowling
2021-07-08 21:47                           ` [TUHS] [tuhs] The Unix shell: a 50-year view Theodore Ts'o
2021-07-09 20:14                             ` Michael Kjörling
2021-07-07 13:54                     ` Tony Finch
2021-07-06 16:05                 ` Clem Cole
2021-07-09 22:19                   ` Tomasz Rola
2021-07-04 20:10           ` Tony Finch
2021-07-05  3:59             ` Theodore Ts'o
2021-07-05 15:08               ` Steffen Nurpmeso
2021-07-05  3:52           ` Bakul Shah
2021-07-04 18:17     ` John Dow via TUHS
2021-07-04 19:46       ` Clem Cole
2021-07-05  1:33         ` Noel Hunt
2021-07-05  2:38           ` Clem Cole
2021-07-05  2:51             ` Warner Losh
2021-07-05  3:03               ` Clem Cole
2021-07-05  3:01             ` Clem Cole
2021-07-05  5:22             ` Noel Hunt
2021-07-06  5:10           ` Nevin Liber
2021-07-06 13:30             ` Clem Cole
2021-07-06 16:23               ` Theodore Ts'o
2021-07-07  1:57                 ` Dan Cross
2021-07-07  2:52                   ` Larry McVoy
2021-07-07  5:19                     ` Andrew Warkentin
2021-07-07 18:28                   ` Jon Steinhart
2021-07-10 11:51                     ` [TUHS] " Ralph Corderoy
2021-07-10 13:54                       ` Henry Bent
2021-07-10 14:12                         ` Ralph Corderoy
2021-07-10 16:57                           ` [TUHS] Death by bug [formerly The Unix shell: a 50-year view] Jon Steinhart
2021-07-11  8:53                             ` [TUHS] Death by bug Ralph Corderoy
2021-07-11  9:04                               ` arnold
2021-07-12  1:42                                 ` Theodore Y. Ts'o
2021-07-12  2:57                                   ` Jon Steinhart
2021-07-12  6:39                                   ` arnold
2021-07-12  9:56                                   ` Ralph Corderoy
2021-07-11 16:10                               ` Jon Steinhart
2021-07-12 10:37                                 ` Ralph Corderoy
2021-07-06 13:40             ` [TUHS] [tuhs] The Unix shell: a 50-year view John Cowan
2021-07-06 14:12             ` Chet Ramey
2021-07-07  0:53               ` Nevin Liber
2021-07-07 13:08                 ` Chet Ramey
2021-07-07 15:15                   ` Richard Salz
2021-07-03  0:09   ` Andrew Warkentin
2021-07-03 15:49   ` Andy Kosela
2021-07-04 23:24     ` [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view) Derek Fawcus
2021-07-04 23:50       ` Nemo Nusquam
2021-07-05  0:15         ` Dan Stromberg
2021-07-05  0:21       ` Larry McVoy
2021-07-05  2:36         ` John Cowan
2021-07-05  2:59           ` Richard Salz
2021-07-05  3:47           ` Larry McVoy
2021-07-05  4:02             ` Dan Stromberg
2021-07-05 13:45               ` Steffen Nurpmeso
2021-07-05 20:15                 ` Dan Stromberg
2021-07-05 21:05                   ` Larry McVoy
2021-07-05 21:29                   ` Clem Cole [this message]
2021-07-05 22:22                     ` Brantley Coile
2021-07-06  4:35                     ` Dan Stromberg
2021-07-06  4:44                       ` Warner Losh
2021-07-06  5:58                       ` Rico Pajarola
2021-07-06 13:05                       ` Clem Cole
2021-07-05 12:11         ` Thomas Paulsen
2021-07-05  4:08       ` Dan Stromberg
2021-07-05  4:23         ` George Michaelson
2021-07-05 14:43           ` Larry McVoy
2021-07-05 15:17             ` Steffen Nurpmeso
2021-07-05 15:36               ` Steffen Nurpmeso
2021-07-05 15:53       ` Mike Markowski
2021-07-05 16:39       ` Warner Losh
2021-07-05 19:02         ` Clem Cole
2021-07-02 22:27 ` [TUHS] [tuhs] The Unix shell: a 50-year view Chet Ramey
2021-07-02 23:09 ` Steve Nickolas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC20D2NZrKPE2V76GTkNPrf_aChBptZW5JEDmo+zUdjWos1vYw@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=drsalists@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).