🚀 go-pugleaf

In article <1990Sep21.130531.7437@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
> jimad@microsoft.UUCP (Jim ADCOCK) writes:
> >One cannot write portable software, and in general take control of the
> >intimate details of structural layout.

> Probably the three languages in which most ported code in existance today
> is written are COBOL, FORTRAN, and C, and each gives _exquisite_ control
> over data "structure" layouts, through COBOL's RECORD, FORTRAN's ARRAY and
> EQUIVALENCE, and C's struct, bitfield, and union functionalities.

COBOL forces you to take control over layout down to the 'character'
level, because COBOL is historically about describing layout on paper
forms.  If you _want_ the compiler to manage layout for you, you have
to use SYNCHRONIZE, which is a pain and (according to a friend of mine
a couple of years ago who did a lot of COBOL coding) isn't portable, in
the sense that you have to move it around for different machines.
Maybe the current COBOL gives you layout control to the bit level; the
version I last used didn't.

So far from giving you "exquisite" control over data structure layout,
the Fortran 77 standard says nothing about how big an integer is except
that INTEGER and REAL are the same size.  Some Fortran compilers support
size controls such as INTEGER*1, INTEGER*2, INTEGER*4, REAL*{4,8,16},
COMPLEX*{8,16,32}, but those are extensions and are not in the standard
language.  Some Fortran compilers even make INTEGER*2, REAL*4 the default,
which is out-and-out wrong according to the standard.  The Fortran 77
storage model is in terms of two kinds of "storage units":  integer and
real take 1 (plain) storage unit, complex and double precision take 2
(plain) storage units, and character*N variables take N character storage
units.  If you overlay character storage units and (plain) storage units,
you haven't got "exquisite control" over layout, you have a non-conforming
program whose behaviour is undefined.  And then there is the well-known
problem of
	REAL X
	DOUBLE PRECISION D
	COMMON /C/ X, D
which may or may not work depending on your machine's alignment requirements;
there is no way to say "put these in the best order so that alignment is
satisfied".  (Fortran 90 MODULEs provide a better way.)

So far from providing exquisite control over layout, C doesn't even define
things like how big an 'enum' is nor let _you_ say.

If you want an example of a standardised language which _does_ provide
control over storage control, look at Ada.

> Successful languages (so far) give complete control where it is demanded
> by the programmer.  There is no particular reason to think a language
> without such facilities will succeed over the long term, so why design one?

Fortran, COBOL, and C have managed ok so far...
-- 
Fixed in the next release.