Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ukma!uflorida!novavax!hcx1!bill From: bill@ssd.harris.com (Bill Leonard) Newsgroups: comp.lang.fortran Subject: Re: Fortran 8x: pointers (long) Message-ID: Date: 10 Jul 89 16:59:11 GMT References: <50500140@uxe.cso.uiuc.edu> Sender: news@hcx1.UUCP Organization: Harris Computer Systems Division Lines: 64 In-reply-to: hirchert@uxe.cso.uiuc.edu's message of 7 Jul 89 16:50:00 GMT > In FORTRAN 77, a PARAMETER statement binds a name directly to a value; an > ordinary variable declaration binds a name to a memory location that can be > bound to a value (1 level indirect), and the appearance of a name in a dummy > argument list has the effect in most implemenatations of binding the name to a > memory location that is bound to a memory location that can be bound to a value > (2 levels indirect). The symbolic constant, the variable, and the dummy > may all be of the same type and are used in exactly the same way when a value > is needed in an expression. Similarly, on the left hand side of an assignment > statement uses the same sytax for an ordinary variable and a dummy variable > in getting to an object that is 1 level indirect to rebind to a new value. > > The Fortran 8x approach to pointers is a logical extension of this situation. > Ordinary objects with the POINTER attribute are 2 levels indirect and dummy > arguments with the POINTER attribute are 3 levels indirect. Syntactic > uniformity is retained in the existing contexts. In the new context, the > pointer assignment statement, the right hand side is uniformly interpreted at > 1 level indirect and the left hand side at 2 levels indirect. > > In other words, one of the reasons Fortran 8x pointers look the way the do is > because the committee chose to be consistent with FORTRAN rather than other > languages that already had pointers. It also offers a number of other > benefits, like keeping simple the notation used to deal with the actual data > and flagging the manipulation of the pointers (the usual source of problems > in pointer algorithms gone wrong), but I consider these benefits secondary to > the consistency issue. I find this whole argument specious. First of all, the discussion of dummy arguments is based on how (most) processors implement them -- it isn't something mandated by the standard. Secondly, "being consistent with FORTRAN" makes no sense; you might as well argue that structures should be just like COMPLEX (i.e., using intrinsics to get at the parts), because that is "consistent with FORTRAN". The obvious retort is that it just isn't what people expect when they think of structures; likewise, what FORTRAN/8x has just isn't what people expect when they think of pointers. > Thus, any algorithm expressable using "conventional" pointers should also > be expressable in the Fortran 8x pointer facility. And any input/output algorithm expressable in FORTRAN is also expressable using only calls to a low-level "get character" routine -- so why have I/O? You know why -- to improve efficiency and readability. Many people seem to have missed the point of the examples using one pointer versus two for linked-list manipulation: it is much more efficient! To a programmer experienced in manipulating linked lists, requiring him to use two pointers is similar to asking a numerical analyst to use back-substitution to solve a system of linear equations. > Pointers would cover this latter functionality if there were > a stand-alone notation for skew sections. I intend to lobby for such a > notation. Because of its limitations, there were some cases where IDENTIFY > could be more fully optimized. I believe most, if not all, of these cases > would be covered by the optimization declarations I mentioned above. God help us. If you think Algol 60 is a great language, I'm sure you'll love this. For those of us who still have nightmares of implementing "call by name", this is even worse: arbitrary functions to be executed upon referencing a pointer! -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net