Path: utzoo!attcan!uunet!lll-winken!sun-barr!olivea!mintaka!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Answers, Chapter 5: some clarifications
Message-ID: <66257@lanl.gov>
Date: 19 Oct 90 21:23:06 GMT
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 98

There has been some confusion among some people posting to the net
about the context of this discussion.  This thread began on the
comp.society.futures and was about the design of _future_ programming
languages.  Many articles have missed that point and have latched on
to some out-of-context part of the discussion and made comments which
were not germane.  The last item on this chapter reintroduces the
original context of the discussion.

> You're repeatedly making statements like these:
>
>   Pointers can never be more efficient than arrays because *(p+i) is
>   just as slow as p[i].

Yes, I do keep making that statement.  It's true, unless you live in a
world of obsolete compilers.  Since my interest is in design of _future_
languages, I don't have any interest in obsolete compilers.

>   Pointers inherently force the programmer not to use any higher-level
>   abstraction.

Indeed, if the higher-level structures are not available or are only
available from preprocessors, the adept user _will_ be forced not
to use the higher-level stuff - unless he's willing to take the
performance hit that preprocessors imply.  So, you're right again,
I _DO_ repeatedly make such statements - and I will continue to do
so.

>   All data structures may be expressed as recursive data structures.

I have _never_ made such a statement.  I _have_ made the statement that
all high-level data structures can be expressed as some combination of
seven structures (and three attributes).  I have sent you a list of such
structures (more than once, I think).  I have posted the list on this
thread at least 4 times (twice, while the thread was still on
comp.society.futures and twice on this newsgroup).  However, I will post
the list again:

1) atomic types (integers, floats, etc.)
2) enumerated types
3) arrays (one or _more_ dimensions)
4) sequences (variable size, one dimensional)
5) unions (always tagged)
6) Records (or STRUCTS, or whatever you want to call them).
7  Recursive data structures (just records with one or more recursive
   components)

Attributes are applicable to individual variables, not to whole data
types.  Attributes are as follows:

a) static, automatic, or dynamic.  The first two are the same as the
   C keywords of the same name (actually, I recommend different keywords,
   but it's the concept I want to expound here - so why complicate things)
   Dynamic means that the variable is not allocated until the user
   specifically allocates space for it, and its lifetime continues
   until the user explicitly deallocates its space (or, possibly its
   automatically garbage collected - if the user is willing to put up
   with the overhead of such a tool).

b) aliased.  This attribute allows any two names of the same type to
   refer to the _same_ object in the system.  The presence of this
   attribute on a variable declaration implies to the compiler that
   all the identifiers in the same declaration _might_ be aliased,
   overlapping, etc..  Such a declaration also tells the compiler
   to allow such variables (and their components) to be assigned to
   each other with the "shallow copy" operator - the only way that
   two things should _ever_ become aliased.

c) map ... as ....  This attribute says that a specific set of variables
   are to be mapped or overlayed (storage association) by some record
   data type.  This permits the machine dependent access to internal
   specifics of the implementation.  The obvious example is the ability
   to bit twiddle floats (for efficient I/O conversion, for example):

      float :: x
      type float_internal               !Internal structure of IEEE float
	 bit.1 :: sign                  !one bit sign
	 int.8 :: exponent              !8-bit biased exponent (treated as
					!a signed integer with 8-bits)
	 int.23 :: significand          !remember, if exponent is zero
					!the use of this must _not_ add
					!a hidden normalization bit on
      end type float_internal

      map x as float_internal

      ...

      x=5.0                             !use x as float
      x.sign = 1                        !make x negative
      x.exponent=x.exponent+1           !double x (assuming it's in range)

It is with a language such as I've described here that I claim that
pointers are redundant.  The examples you've given so far have failed
miserably to convince me that I'm wrong.

End of chapter 5

J. Giles