Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <63218@lanl.gov>
Date: 17 Sep 90 23:15:59 GMT
References: <1990Sep14.212806.8131@abcfd20.larc.nasa.gov>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 89

From article <1990Sep14.212806.8131@abcfd20.larc.nasa.gov>, by jcburt@ipsun.larc.nasa.gov (John Burton):
> [...]
>                         I guess the point I was trying to make was
> that pointers are NOT difficult to understand AND they provide
> much needed flexibility...

Really?  Iv'e been asking this same question for over two years
on the net - no one has yet answered it:  Please give me a specific
example of a _legal_ C data structure which _cannot_ be implemented
with the same efficiency with the data structuring features below.
Note, there is not a _single_ explicit pointer data type in the
following list.

1) 'Atomic' types (floats (various sizes), ints (various sizes), booleans,
   characters (various character sets), etc....)

2) Enumerated data types.  These are simply a vay to allow the user to
   invent a new 'atomic' type.

3) Arrays.  Mappings from a tuple of indices to a typed value.  Note: an
   array of arrays is legal and is _NOT_ the same as a 2-d array (although
   a little syntactic sugar could allow this later - no one has ever asked
   for it).

4) Sequences.  An ordered collection of zero or more objects to be
   accessed in a specific order.  Obvious syntactic sugar (like direct
   referencing of the last element or an arbitrary element) is permitted.
   The usual implementation of character strings in C is an example of an
   inefficient implementation of a sequence.  You can have a sequence of
   any data type (including a sequence of sequences - which is what a
   dictionary is).

5) Records.  Like C struct.  No difference at all really.

6) Unions.  These are _always_ discriminated.  The compiler is
   responsible for maintaining and checking the type tags.  Note that
   this only _seems_ inefficient: _legal_ C programs should always
   explicitly maintain a tag anyway.

7) Recursive types.  These may be given the attribute 'aliased' in order
   to allow circular and overlapping references.  Other than that, we have
   discussed these before.

In addition, all variables can be declared with a 'dynamic' attribute,
which means that they must be allocated before use (dynamic arrays give
their size at allocation time).  It might be desireable for sequences
and recursive data type to be given the dynamic attribute automatically.

I can demonstrate sample syntax for these if anyone thinks it is required.
Anyone who proposes a C data object that he claims is not representable
here is invited to do so (I'm not joking - I'm designing a language with
these features - this challenge is an attempt to find out whether I'm
leaving something out).

> [...]
>>Programming is a skill, like driving a semi, most people shouldn't
>>need that skill.
> 
> Exactly!!! Programmers should help provide the tools for non-programmers
> to use...Programming languages SHOULD NOT be restricted to provide
> safety for novice/non-programmers at the expense of those that can
> benefit from the flexibility of "dangerous" attributes such as pointers...
> [...]

I agree completely ... except with the last line.  Pointers are a bad
example of the philosophy you are discussing.  The presence of pointers is
an example of something useful having been _left_out_ of programming
languages.  Making me use pointers when what I really _want_ is dynamic
memory, or arrays, or sequences, or recursive data structures, etc.; is
like forcing the semi driver to use a crank to start his truck.  We give
semi trucks electric starters because it is a simple, reliable, and easy
to use replacement for the crank (in the role of truck starter anyway).
In fact, the electric starter is _so_ good, they no longer bother
providing cranks for trucks (or, any way to use a crank even if you had
one).  In fact, truck engines are now so large and heavy, you couldn't
turn it over by hand anyway - the presence of the starter has made it
possible to design larger and more powerful trucks than would otherwise
be possible.

A programming language should be designed with simple, reliable, and
easy to use replacements for hardware level concepts as well - or
would you rather have only conditional jumps for flow control and bit
twiddling for data?  The presence of more powerful language features
should allow programmers to concentrate on _what_ they want the code
to do, not _how_ the machine does it internally.  This should make
possible larger and more powerful programs than are presently feasible
with sufficient reliability.

J. Giles