Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Summary: Don't invent new idioms for existing languages
Message-ID: <11935@pur-ee.UUCP>
Date: 14 Jun 89 15:09:32 GMT
References: <2716@elxsi.UUCP> <13934@lanl.gov> <135@unmvax.unm.edu>
Reply-To: hankd@pur-ee.UUCP (Hank Dietz)
Distribution: usa
Organization: Purdue University Engineering Computer Network
Lines: 104

In article <135@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes:
>In article <13934@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>> 
>> The new pointers _DO_NOT_ provide the functionality of the deleted features.
>> Pointers cannot be used to implement either the RANGE attribute or the
>> IDENTIFY statement.  This is because pointers can only alias _contiguous_
>> memory locations - which is an insignificant subset of the capabilities
>> of the two features that have been removed.
>> 
>I have just received the latest version of the X3J3 draft
>and I see nothing that restricts a pointer target to an object
>that is in contiguous storage.  The target must not involve a _vector_
>subscript, but may be, for example, a row of an array, which, if stored
>in the traditional way, will not be in contiguous storage.  I.e.,
>unless I am missing something, the following is legal:
>
>REAL, DIMENSION (100, 100), TARGET :: A
>REAL, DIMENSION (100), POINTER :: P
>   . . .
>P => A (50, :)  ! P IS AN ALIAS FOR ROW 50 OF A
>
>As Scott Lamson pointed out, this isn't legal unless A has the target attribute.
>
>The following 2 paragraphs do NOT refer to Jile's article:
>
>Someone else wanted the syntax to be something like
>POINTER TO, REAL :: P1, P2
>but statements of this form are simply extensions of the F77 type statements,
>which all begin with the name of a type and may be followed by various
>attribute like DIMENSION, TARGET, POINTER, SAVE, PARAMETER, etc.,
>so it wouldn't be good to change the syntax for just one of them.
>
>The reason the default is to dereference pointers in most contexts
						      ^^^^
>is that it is believed that a large majority of pointer use is
>to reference its target and the default should be the case that
>is most frequent.  The down side is perhaps that other languages
>do it the other way (every once in a while, it's done right in Fortran!).

I haven't seen the standard, but it sure sounds to me like a mistake to
imply dereference sometimes and not at other times.  Always implying a
dereference UNLESS it is explicitly prevented seems the way to do this.

>> The only _new_ functionality provided by pointers is the ability to
>> define recursive data structures.  But this capability would have been
>> easier to define and implement by _really_ allowing recursive structure
>> (derived type) declarations.
>> 
>I certainly agree with this.
>True recursive data structures were proposed to X3J3,
>but this idea is much too radical for the current membership.
>It's not the Fortran way (too elegant!).

More to the point, it isn't recognizable as Fortran.

I feel as though I am on a one-man crusade to prevent languages from getting
cluttered with so many alternative ways of expressing the same thing.  The
reasons I object are very simple (note: I'm an optimizing/parallelizing
compiler person):

[1]	More constructs, bigger and more complex compiler....

[2]	Quite likely, most compilers will do better generating code for some
	alternatives than for others, but which ones will vary from one
	compiler to the next.  Hence, code efficiency may vary widely based
	on which alternative expressions the compiler writers thought were
	most important.

[3]	Given a plethora of different alternatives, programmers will each
	chose a subset of the language and work within this subset.  Fine,
	you say, but there is no reason to expect that people would chose
	the same subset.  In other words, two top-notch Fortran programmers
	might write code in idioms so different that neither can understand
	the other's code (or even recognize it as valid Fortran).

	Developing an idiom is important in becoming a good programmer; the
	problem is when different programmers pick very different idioms.
	For example, in C *everybody* uses uppercase names for macros and
	lowercase for variables, etc.  It is truly confusing when one comes
	across a program written by someone who uses a different idiom.  Now,
	C doesn't require that people use that idiom, but I'd rather it did.
	The only reason that C is usable this way is that THE C reference
	uses this idiom exclusively...  a lot of folk don't even know that
	the language doesn't require this naming scheme.

This third problem is by far the worst.  In the new Fortran, I'm afraid this
kind of problem will be several orders of magnitude worse than it has been
for any other language...  there will still be *lots* of people using the
ANSI66 idioms, the ANSI77 idioms, and there will be people using the new
idioms.  I started with ANSI66 and, quite honestly, I still do a doubletake
when I see ELSE in "Fortran" code.  And I am a compiler writer and
researcher -- quite aware of the precise language definitions -- but ELSE
isn't in *my* Fortran idiom.

So, I'm opposed to pointers in Fortran on the basis that pointers are *very*
alien to the existing Fortran idioms.  Translation:  if you want pointers,
use C or some other language where that construct is understood by most
programmers -- it is part of anyone's idiom.  Creating new idioms in a
language without changing the name of the language is a really bad idea.  If
making Fortran be everything to everyone means making Fortran the union of
many different sublanguages (disjoint idioms), then it's a lie to call it
Fortran.

						-hankd@ee.ecn.purdue.edu