corbett@beatnix.UUCP (Bob Corbett) (06/07/89)
How does one get the most recent ANSI Fortran 8x drafts? Observer status with X3J3 does not cut it. ELXSI has had observer status for the past two years and has yet to receive a copy of the draft standard. All observer status buys is minutes of the X3J3 meetings (often long after they occurred). The latest draft I have obtained is the March 1989 version. After reading news about recent X3J3 meetings on the net, I expected the language to be in even worse shape than it was at the time of the first public review. In fact, the language is much improved over the public review version. If X3J3 continues to improve the language at the current rate, it should be ready for the next public review in just a couple of years. Pointers are the most significant addition to the language since the public review. Pointers made it possible for X3J3 to remove some of the most bizarre features of the public review version of the language without losing any functionality. However, the pointer mechanism described in the March 1989 draft of the standard is itself somewhat bizarre. It also lacks some of the functionality usually provided by pointers. A key difference between pointers in Fortran 8x and pointers in other languages is that there are no pointer types. POINTER is an attribute. For example, a pointer variable P might be declared as REAL, POINTER :: P One problem is that there does not seem to be a way to declare a pointer to a pointer. The declaration REAL, POINTER, POINTER :: P is illegal. Pointers to pointers are seldom needed, but it is going to be painful not to have them on those occasions when they are needed. On the other hand, I cannot think of a case where I have needed a pointer to a pointer to a pointer. It may be possible to get around the lack of pointers to pointers by declaring structure types with a single field consisting of a pointer, and then declaring a pointer to that structure type. I find this solution distasteful. Writing the POINTER attribute after the type seems conceptually backward. I would prefer a syntax such as POINTER TO, REAL :: P In the source form that makes blanks significant, the comma could be made optional. The committee has chosen to use implicit dereferencing. For example, if I is a pointer to an integer, the statement I = I + 1 will increment the value referenced by I rather than I itself. A pointer assignment statement must be used to assign to a pointer. The form of a pointer assignment statement is pointer => target Pointers cannot be set to null via assignment. A NULLIFY statement must be used instead. The form of a NULLIFY statement is NULLIFY(pointer-name-list) I would prefer explicit dereferencing. The use of pointers frequently involves aliasing. Any use of aliasing should be denoted explicitly. Perhaps the ? character could be used to denote an explicit dereferencing operator. I suspect a user would be more likely to guess that the incrementing assignment shown above involves a potentially dangerous operation if it were written as ?I = ?I + 1 Note that requiring explicit dereferencing eliminates the need for the pointer assignement statement and the NULLIFY statement. Faithfully yours, Bob Corbett uunet!elxsi!corbett ucbvax!sun!elxsi!corbett
corbett@beatnix.UUCP (Bob Corbett) (06/08/89)
I cannot understand why X3J3 refuses to add horizontal tabs to the Fortran character set. To my knowledge, there are no longer any machines being produced that do not include a horizontal tab in their character set. Differences between tabbing conventions are a major obstacle to portability. Users do not like being told that they should not have put tabs in their codes if they wanted them to be portable. Yours very truly, Bob Corbett uunet!elxsi!corbett ucbvax!sun!elxsi!corbett
corbett@beatnix.UUCP (Bob Corbett) (06/09/89)
One feature of Fortran 8x I find particularly annoying is that the type
definition facility permits only record types to be defined. The lack of a
general type definition mechanism becomes even more irritating now that KIND
selectors have been added to the language. Suppose a machine supports 64-bit
integers. The Fortran 8x implementation for such a machine might permit
64-bit integer entities to be declared with a syntax such as
INTEGER(64) :: entity-decl-list
The number 64 is the kind selector. Suppose a programmer is trying to write
a program for several different machines, and he or she has lots of data
object declarations for objects he or she wishes to be of the largest supported
integer type. If the language supported a general type definition facility, he
or she could place a definition of a type, say LONGEST_INT, in an INCLUDE file,
and then use that type wherever it is needed. The closest the current draft of
the standard will allow him or her to come to that solution is to allow a
definition of a structure containing a single field of the longest integer type.
The definition might take the form
TYPE LONGEST_INT
INTEGER(64) V
END LONGEST_INT
The data objects could then be declared using type declarations of the form
TYPE(LONGEST_INT) :: entity-decl-list
The problem with this approach is that to reference the data objects,
component selectors must be used. For example, to increment a variable I
of type LONGEST_INT, the programmer would have to write
I%V = I%V + 1
There has got to be a cleaner way. Some of the more exotic programming
languages, such as C and Pascal, allow type definitions for arbitrary data
types. I think X3J3 would do well to see how those languages manage to handle
this apparently difficult concept.
KIND selectors are an inherently implementation-dependent feature. I have
no objection to adding implementation-dependent features to a language, but I
feel they should be clearly marked as such. The draft standard requires a
conforming processor to contain the capability to detect and report the use of
kind type parameters not supported by the implementation. This requirement
seems a bit weak. I can easily imagine
INTEGER(8)
meaning an 8-bit integer in one implementation, a 48-bit integer in another,
and a 64-bit integer in another. The requirement should be strengthened to be
the capability to detect and report all uses of KIND selectors.
The use of KIND selectors for integer types is distasteful, since a
range mechanism could provide the same capability in a portable way. However,
given that no similar mechanism will work for character, logical, and
floating-point data types, consistency argues for the use of KIND selectors
for integers as well.
Yours very truly,
Bob Corbettdd@beta.lanl.gov (Dan Davison) (06/11/89)
In article <2716@elxsi.UUCP>, corbett@beatnix.UUCP (Bob Corbett) writes: > Pointers are the most significant addition to the language since the public > review. Pointers made it possible for X3J3 to remove some of the most bizarre > features of the public review version of the language without losing any > functionality. if you are referring to range and identify, i disagree. the pointer mechanism in the current draft completely blows optimization (except perhaps peephole-type optimization). an utterly bizarre decision. i *want* pointers, but i want my fortran to fly, and it won't the way the current draft reads. on this point alone my review comments will be strongly negative. i will comment further when the draft is made public. -- dan davison/theoretical biology/t-10 ms k710/los alamos national laboratory los alamos, nm 875545/dd@lanl.gov (arpa)/dd@lanl.uucp(new)/..cmcl2!lanl!dd
lamson@sierra.steinmetz.ge.com (scott h lamson) (06/12/89)
>the pointer >mechanism in the current draft completely blows optimization (except >perhaps peephole-type optimization). an utterly bizarre decision. >i *want* pointers, but i want my fortran to fly, and it won't the >way the current draft reads. After hearing Walt Brainerd's seminar on the current draft standard (Very worth while!!), my understanding is that the bad things pointers will do to optimization will only impact arrays that have the TARGET attribute (at least if the compiler implementation is "good enough"). If you use TARGET sparingly, you should be able to maintain efficient code generation. I spoke against voilating Fortran with pointers in the first public review, but I will be reconsidering that position for the second. For both up to date information on the current draft as well as an appreciation of how the proposed language can be used, I highly reccomend Brainerd's seminar. You can contact him at brainerd@unmvax.cs.unm.edu. -- Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson
bill@ssd.harris.com (Bill Leonard) (06/12/89)
> I cannot understand why X3J3 refuses to add horizontal tabs to the > Fortran character set. To my knowledge, there are no longer any machines > being produced that do not include a horizontal tab in their character > set. Differences between tabbing conventions are a major obstacle to > portability. Users do not like being told that they should not have put > tabs in their codes if they wanted them to be portable. Well, one reason is that we can't get a majority to agree on what a tab would mean. Those who want tabs usually want it to mean "however many spaces it produces on my terminal when I display the file" -- try getting that into a standard! The problem really lies in the fact that, while tab is a "standard" character, it has an implementation-defined meaning. In fact, on some systems the user can change the tab settings, thus changing the "meaning" of tab dynamically! If all X3J3 did were to allow tabs in source files, but didn't specify it's meaning, portability would not improve one iota. I, personally, have never understood why any designer of a text editor or other source-processing system should ever put a tab character in a source file. The tab key, originally, was simply a time-saver for typists to avoid having to hit the space bar many times. I think it should remain just that, and the text-processing system should translate it to the proper number of space characters. One of the many reasons I hate the 'vi' editor is its insistence on inserting tabs, even when I didn't hit the tab key!!!! "Doctor, it hurts when I do this!" "Then don't do that." -- 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
jlg@lanl.gov (Jim Giles) (06/13/89)
From article <2716@elxsi.UUCP>, by corbett@beatnix.UUCP (Bob Corbett): > [...] > Pointers are the most significant addition to the language since the public > review. Pointers made it possible for X3J3 to remove some of the most bizarre > features of the public review version of the language without losing any > functionality. [... 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. Not only that, but pointers cause a more significant degradation of code efficiency than RANGE and IDENTIFY would have - so even if pointers _could_ provide the functionality, they are not desireable. Pointers can be used to dynamically allocate memory. But, since ALLOCATABLE variables are retained by the new proposal, ALLOCATABLE remains the prefered method of dynamic memory allocation (no aliasing problems). 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 was marginally in favor of pointers at the last 8x review period (mainly to allow recursive data structures). Since studying the issue more thoroughly though, I am convinced that pointers should be included only in _VERY_ low level languages (or, perhaps only systems programming languages). Fortran doesn't need pointers and, in fact, the functionality provided by pointers would be better provided by other means.
brainerd@unmvax.unm.edu (Walt Brainerd) (06/13/89)
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!). > 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!).
khb@chiba.Sun.COM (chiba) (06/13/89)
In article <2716@elxsi.UUCP> corbett@beatnix.UUCP (Bob Corbett) writes: >How does one get the most recent ANSI Fortran 8x drafts? Observer status with >X3J3 does not cut it. ELXSI has had observer status for the past two years and >has yet to receive a copy of the draft standard. All observer status buys is >minutes of the X3J3 meetings (often long after they occurred). You should be getting the minutes when the rest of us get them... don't forget all of the folks who scribe them have jobs .... I do not understand why you did not get the new draft; observers are slated to get them. Send email to fortran@ibm they owned mailing the last set out (but they used the labels generated by those who own the mailing list). Mostly, I suspect you fell off (or never got on) someone's list. > >The latest draft I have obtained is the March 1989 version. After reading news >about recent X3J3 meetings on the net, I expected the language to be in even >worse shape than it was at the time of the first public review. In fact, the >language is much improved over the public review version. If X3J3 continues to >improve the language at the current rate, it should be ready for the next public >review in just a couple of years. The next review will probably be this fall. The rest of the world is moderately happy and it seems likely that it will be an ISO standard soon. > >Pointers are the most significant addition to the language since the public >review. Pointers made it possible for X3J3 to remove some of the most bizarre >features of the public review version of the language without losing any >functionality. However, the pointer mechanism described in the March 1989 >draft of the standard is itself somewhat bizarre. It also lacks some of the >functionality usually provided by pointers. The object of the exercise is not to make fortran==C. There were vendors and users... for the most part users wanted pointers and they got what they demanded. If C pointers were introduced there would have been even stronger objections (as it was, I think Cray's vote turned from yes to no largely on the inclusion of pointers into the language ... this is only my opinion based on chats, their Public Comment may be construed differently). .... stuff about rare pointer usage Those who really wanted the feature crafted proposals. They had a set of things which they felt should be accomplished by a fortran pointer facility, and took great pains to ensure that their needs were taken care of. There is no reason why Elxsi couldn't have crafted a "clearly superior" proposal. Even getting minutes late, and not being willing to attend any meetings, text could have been supplied in the year since it was clear that there would be a pointer added (due to public demand). Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
khb@chiba.Sun.COM (chiba) (06/13/89)
In article <LAMSON.89Jun12080858@sierra.steinmetz.ge.com> lamson@sierra.steinmetz.ge.com (scott h lamson) writes: > >>the pointer >>mechanism in the current draft completely blows optimization (except >>perhaps peephole-type optimization). an utterly bizarre decision. >>i *want* pointers, but i want my fortran to fly, and it won't the >>way the current draft reads. > >After hearing Walt Brainerd's seminar on the current draft standard >(Very worth while!!), my understanding is that the bad things pointers >will do to optimization will only impact arrays that have the TARGET >attribute (at least if the compiler implementation is "good enough"). >If you use TARGET sparingly, you should be able to maintain efficient >code generation. I spoke against voilating Fortran with pointers in >the first public review, but I will be reconsidering that position for >the second. The final impact of pointer is hotly disputed. For those applications which NEED pointer (e.g. doubly linked list manipulation) the cost is proabably quite acceptable. Adopting a C-like coding style will probably trash optimization. So those of us want to go fast, will mostly use arrays, dynamic, static, sections and old-style.... reserving pointers for special (rare) purposes. > >For both up to date information on the current draft as well as an >appreciation of how the proposed language can be used, I highly >reccomend Brainerd's seminar. You can contact him at >brainerd@unmvax.cs.unm.edu. > Walt does a good job. FORTEC Forum and the Fortran Journal are also worthwhile sources of information. When I have converted the disks (probably tomorrow) I will be posting Prof. Meissner's (sp ?) summary (part I). The good prof. is editor of the Forum, and has granted everyone the right to re-distribute his summary. While I do not want folks to not go and read the whole thing, the text of the offical standard is quite obtuse (it is in the nature of the beast) and well thought summaries (or even Metcalf and Reid's now out of date text) really do a better job of getting the overall picture, and philosophy of the language across. At the very least, one should study them _before_ ordering the text from Global.... Cheers all. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
shapiro@rb-dc1.UUCP (Mike Shapiro) (06/14/89)
In article <BILL.89Jun12125206@hcx2.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes, regarding horizontal tabs in Fortran source: >Well, one reason is that we can't get a majority to agree on what a tab >would mean. Those who want tabs usually want it to mean "however many >spaces it produces on my terminal when I display the file" -- try getting >that into a standard! The problem really lies in the fact that, while tab >is a "standard" character, it has an implementation-defined meaning. In >fact, on some systems the user can change the tab settings, thus changing >the "meaning" of tab dynamically! If all X3J3 did were to allow tabs in >source files, but didn't specify it's meaning, portability would not >improve one iota. One possible partial solution, which can be considered implementation-independent, is that used in Gould Common Fortran: A tab character in any of the first six positions of a line is interpreted as a skip to position 7. This indi- cates that all the following characters in the line are to be treated as a statement. A tab character anywhere else in the line is treated as a space. This rule seems to apply to the statement form, indicating a statement must be from columns 7 through 72. It doesn't say whether a tab character can be part of a character constant and, if so, what it means. The new dpANS Fortran allows the fixed format as an option and a new free format, eliminating the column restrictions. The new standard allows tab characters (as additional characters representable on the processor) in "character constants, character string edit descriptors, comments, and input/output records." I have the feeling that many implementors will allow tabs elsewhere in free form source, treating them as spaces for the 132 characters in a line limit. -- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1 (This location will close, starting July 10. I will be moving on.)
khb@chiba.Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (06/14/89)
In article <BILL.89Jun12125206@hcx2.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes: >.... >I, personally, have never understood why any designer of a text editor or >other source-processing system should ever put a tab character in a source >.... No :>, so I guess you must be serious. Most modern systems have nifty things, like proportional fonts, multi-sized fonts etc., and then tab has the meaning of going to the place defined (i.e. tab stops). In a programming language (say vmsfortran, a language descended from, but not that similar to fortran :> :> :>) one might chose to define <tab> as a special symbol ... to "space over" line numbers, for example. Tab belongs on keyboards. It probably belongs in one of those extended character sets in f88. It probably has no use as a <symbol> in a sensible language environment, but is perfect as the <space over> key to strike. gnuemacs tends to treat it (for .f files) as the autoindent command (though one has to get used to tabbing AFTER typing). There does seem to be little merit in having the <tab> symbol embeded in source code... yet another reason to not use vi. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
jlg@lanl.gov (Jim Giles) (06/14/89)
From article <135@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > 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. [... I also have seen the June release of the standard. I see nothing that _requires_ pointers to be anything but an address with a type attribution. At present, the semantics of pointer variables are not adequately described in the proposals. If Brainerd is correct, however, then I am more against pointers than I was before - the committee is compounding too many _separate_ functionalities into a single construct. > ...] 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 In order to implement this, the pointer must actually be (what used to be called) a 'dope vector'. This is an outgrowth of that overloading I mentioned - by putting this functionality into the POINTER they are no longer pointers! Instead of the above, why not have: REAL, DIMENSION (100, 100) :: A REAL, DIMENSION (100), ALIAS :: P P <=> A (50, :) ! P IS AN ALIAS FOR ROW 50 OF A Now, P really is an alias for A(50, :) and every use of P should be treated as if A(50, :) had been written (at least until the next assignment to P). This still doesn't allow the full functionality of INTENTIFY, but it doesn't overload pointers either. Note: the above works only if P is not allowed as a common variable, thus making the fact that A has been aliased locally detectable - One of the problems with using pointers for this is that non-local pointers must be assumed by the compiler to be aliased to all other pointers and all TARGET variables, nothing more can be statically determined. Traditionally, pointers in low-level languages have served many purposes. In a high-level language, pointers have nearly _no_ useful roles. If Fortran had an explicit aliasing capability (IDENTIFY was good), plus a dynamic memory allocation mechanism (ALLOCATABLE is good), plus a recursive data structuring capability, then pointers would not be needed at all. I am certainly against compounding all these separate features into one syntactic form.
brainerd@unmvax.unm.edu (Walt Brainerd) (06/14/89)
In article <13937@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <135@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > > 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. [... > > I also have seen the June release of the standard. I see nothing that > _requires_ pointers to be anything but an address with a type attribution. > You did see something that requires it as you convincingly point out in the next paragraph. > > ...] 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 > > In order to implement this, the pointer must actually be (what used to be > called) a 'dope vector'. Exactly right! And the standard requires that this be implemented! > . . . Instead of the above, why not have: > > REAL, DIMENSION (100, 100) :: A > REAL, DIMENSION (100), ALIAS :: P > > P <=> A (50, :) ! P IS AN ALIAS FOR ROW 50 OF A > This is exactly what is there, except for small syntactic changes! <=> is used instead of => ALIAS is used instead of POINTER the TARGET attribute is missing in the declaration of A, which, as has been pointed out, is only there to help the compiler to optimize.
hankd@pur-ee.UUCP (Hank Dietz) (06/14/89)
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
brainerd@unmvax.unm.edu (Walt Brainerd) (06/15/89)
In article <11935@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes: > More to the point, it isn't recognizable as Fortran. > ... > I started with ANSI66 and, quite honestly, I still do a doubletake > when I see ELSE in "Fortran" code. > ... > 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. I don't understand. You say it is alien to Fortran, but it is part of anyone's idiom. So if you are capable of making the switch to C, why are you startled by the radical new ELSE statement and the possible introduction of pointers? Switching to C is a perfectly reasonable thing to do in some circumstances, but a great many Fortran programmers to not have that option, and they have jobs to get done for which pointers, recursion, data structures, and all kinds of new 1970s type software innovations are very helpful.
jlg@lanl.gov (Jim Giles) (06/15/89)
From article <143@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): >> I also have seen the June release of the standard. I see nothing that >> _requires_ pointers to be anything but an address with a type attribution. > > You did see something that requires it > as you convincingly point out in the next paragraph. > >> > ...] 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 >> >> In order to implement this, the pointer must actually be (what used to be >> called) a 'dope vector'. > > Exactly right! And the standard requires that this be implemented! Since Walt is on the committee (or was - I don't know his present status), I will assume he is right about the interpretation of the standard. I was only pointing out that the present proposal, as written, does _not_ give any _semantic_ interpretation for the above example. At least to my mind, a comment on a example statement does _not_ constitute an adequate definition of the semantics of a programming language feature. If they intend for a POINTER value to actually be an entire array descriptor or 'dope vector', then they should say so explicitly and fully describe what that means. Failure to do so indicates to me that the meaning of POINTER is not well defined. Of course, if POINTER is supposed to be defined as Walt claims, it isn't really a pointer. So it's misleading to people who know pointers from other languages. Furthermore, it needlessly complicates the semantics of pointers when they are used in more conventional roles (recursive data structures, for example).
hankd@pur-ee.UUCP (Hank Dietz) (06/15/89)
In article <145@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <11935@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes: >> More to the point, it isn't recognizable as Fortran. >> ... >> I started with ANSI66 and, quite honestly, I still do a doubletake >> when I see ELSE in "Fortran" code. >> ... >> 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. > >I don't understand. You say it is alien to Fortran, but it is part of anyone's >idiom. So if you are capable of making the switch to C, why are you startled >by the radical new ELSE statement and the possible introduction of pointers? I'm not surprised to find a steering wheel in a car, but I'd be a bit startled to find one on a motorcycle. Wouldn't you be? I'd be even more upset to find both handlebars and a steering wheel. The example of ELSE in ANSI77 is admittedly extreme, but I am quite serious about it not being part of my Fortran idiom.... I was involved in the ACM Programming Contests back when they required use of pure ANSI66, hence, I learned to use a pure ANSI66 Fortran idiom. Also, ANSI77 conforming compilers used to be hard to find, hence careful ANSI66 code was *much* more portable. Incidentally, even then my "native" language was C. Old C, not the *mildly* incompatible thing becoming known as ANSI C.... I like the new function prototypes, etc., but I'm not thrilled about ANSI C being incompatible with old C and still being called C. Get the point? There should be one and only one standard for each language... the new (upgraded?) languages ought to be given new names. Truth in advertising and all that. >Switching to C is a perfectly reasonable thing to do in some circumstances, >but a great many Fortran programmers to not have that option, >and they have jobs to get done for which pointers, recursion, data structures, >and all kinds of new 1970s type software innovations are very helpful. My point is that suddenly redefining "Fortran" to be a language which supports "pointers, recursion, [and] data structures" is really defining a completely new language (i.e., set of idioms). An Fortran (ANSI77) wizzard isn't necessarily going to understand what those pointer thingies are doing in some new Fortran program he's handed... does that mean he's no longer a Fortran wizzard? Even ANSI77 was significantly different from ANSI66, but the new "Fortran" will be *very* different. It will be "Fortran" in name only (even lexically different!). If you want a more modern language which maintains some of the structure of Fortran, *add* the new constructs and *remove* the old ones supporting outdated idioms (e.g., comparatives like .GT., arithmetic IFs, etc.) and then come up with a new name for it. Heck, add classes and call it F++ (or would that be D-?) ;-). If you care about old Fortran code, supply an ANSI77 to F++ conversion program with the F++ standard. Just don't tell me it is "standard Fortran." -hankd@ee.ecn.purdue.edu PS: Usually, I don't flame like this, but *somebody* had to say this stuff. PPS: Notice that people talk about 66, 77, and 8x rather than Fortran; I suppose calling Fortran-like languages by numeric names makes sense. ;-)
brainerd@unmvax.unm.edu (Walt Brainerd) (06/15/89)
In article <13938@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > >> > REAL, DIMENSION (100, 100), TARGET :: A > >> > REAL, DIMENSION (100), POINTER :: P > >> > . . . > >> > P => A (50, :) ! P IS AN ALIAS FOR ROW 50 OF A > >> > >> In order to implement this, the pointer must actually be (what used to be > >> called) a 'dope vector'. > > > > Exactly right! And the standard requires that this be implemented! > > Since Walt is on the committee (or was - I don't know his present status), He is still on it. > I will assume he is right about the interpretation of the standard. I was Not necessarity a good assumption, in general! > only pointing out that the present proposal, as written, does _not_ give > any _semantic_ interpretation for the above example. At least to my mind, > a comment on a example statement does _not_ constitute an adequate definition > of the semantics of a programming language feature. If they intend for a > POINTER value to actually be an entire array descriptor or 'dope vector', > then they should say so explicitly and fully describe what that means. > Failure to do so indicates to me that the meaning of POINTER is not well > defined. My example doesn't provide the semantics, but the standard does. The syntax is pointer-name => target An instance of a target, if you follow thru the syntax, is an array section, as in the example above. The semantics are given by: "A pointer assignment statement associates a pointer with a target." The term "associated" is widely used in the standard; very roughly, it means they are aliased. In the example above, this means that I can PRINT *, A (50, 23) or PRINT *, P (23) with the same result. The standard cannot suggest an implementation, such as a dope vector; it can only describe what must happen. > > Of course, if POINTER is supposed to be defined as Walt claims, it isn't > really a pointer. So it's misleading to people who know pointers from > other languages. Furthermore, it needlessly complicates the semantics > of pointers when they are used in more conventional roles (recursive > data structures, for example). I don't follow this. It simply means it can point to more complex objects than in many languages. I also don't see how it complicates things when pointers are used to implement recursive data structures; if you have "nodes" in a linked list consisting of an integer (say) and a pointer to the next node, then, thinking truly of recursive data structures, the pointer is just an alias for the rest of the list. So a list of integers is either empty or a) an integer and b) a list of integers (i.e., the pointer component). Walt Brainerd, Unicomp, Inc. brainerd@unmvax.unm.edu
jlg@lanl.gov (Jim Giles) (06/16/89)
From article <147@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > In article <13938@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: >> Of course, if POINTER is supposed to be defined as Walt claims, it isn't >> really a pointer. So it's misleading to people who know pointers from >> other languages. Furthermore, it needlessly complicates the semantics >> of pointers when they are used in more conventional roles (recursive >> data structures, for example). > > I don't follow this. It simply means it can point to more complex > objects than in many languages. I also don't see how it complicates > things when pointers are used to implement recursive data structures; > [...] If you haven't got a complete definition of the semantics of POINTERS, I don't see how you can verify that the new functionality doesn't contain non-intuitive 'gotchas' when pointers are used in their more conventional roles. As you say, POINTERS can 'point' (actually whole dope vectors are involved) to more complex objects: which means that this increase in complexity _can_ take place inadvertently - especially if the pointer is defined in a MODULE or INCLUDE file and the pointer assignment is non-local also. A complete specification of the semantics of POINTERs would satisfactorily answer this issue. It _is_ possible to define semantics _without_ specifying implementation details. Also, if the new functionality is separable from the old, traditional, uses of pointers, why does this new functionality share the same syntax? This violates the principle of orthogonality in language design. Separate features should have separate syntax. So: aliasing array sections should be _different_ than implementing recursive data structures!
bill@ssd.harris.com (Bill Leonard) (06/17/89)
In article <561@rb-dc1.UUCP> shapiro@rb-dc1.UUCP (Mike Shapiro) writes: One possible partial solution, which can be considered implementation-independent, is that used in Gould Common Fortran: > A tab character in any of the first six positions of a > line is interpreted as a skip to position 7. This indi- > cates that all the following characters in the line are > to be treated as a statement. A tab character anywhere Hmmm, you missed my point entirely, I'm afraid. I didn't say there wasn't a possible interpretation, but that there are many! I also tried to point out that many people want the interpretation to correspond with the visual interpretation they get from whatever display device they use, but that those vary from device to device. I recall from when I worked on the FORTRAN compiler for Gould that some customers complained that a tab in their source skipped to column 7, but the terminal did not! -- 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
brainerd@unmvax.unm.edu (Walt Brainerd) (06/17/89)
In article <13939@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > If you haven't got a complete definition of the semantics of POINTERS, > In my last posting, I quoted verbatim the complete semantics of pointers quoted directly from the new proposed standard. > Also, if the new functionality is separable from the old, traditional, > uses of pointers, why does this new functionality share the same syntax? > This violates the principle of orthogonality in language design. Separate > features should have separate syntax. So: aliasing array sections should > be _different_ than implementing recursive data structures! The _point_ I was trying to make with the example, is that the "new" and "old" uses are exactly the same and _should_ share the same syntax. If you think of a pointer as just an ADDRESS (possibly one that can be incremented and multiplied by 7, etc.), (this sort of thing certainly has occurred in Fortran implementions) then the proposed Fortran pointers do not fit with that model. If you think of a pointer as a POINTER (pointing to, referencing, or aliasing another object), then all uses of pointers in the proposed Fortran standard fit within this notion (including "tradidional" uses of pointers to implement linked lists and other data structures). In summary, the uses and description of pointers are consistent as proposed; it may not fit some notions of what people have thought of as pointers. Walt Brainerd Unicomp, Inc. brainerd@unmvax.unm.edu
jlg@lanl.gov (Jim Giles) (06/17/89)
From article <150@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > [...] > If you think of a pointer as just an ADDRESS > (possibly one that can be incremented and multiplied by 7, etc.), > (this sort of thing certainly has occurred in Fortran implementions) > then the proposed Fortran pointers do not fit with that model. > [... That is _exactly_ the model of pointers I have in mind (with the addition of typed pointers so static type checking of the pointee is possible). > ...] > If you think of a pointer as a POINTER (pointing to, referencing, or aliasing > another object), then all uses of pointers in the proposed Fortran standard > fit within this notion (including "tradidional" uses of pointers > to implement linked lists and other data structures). > [... I have _never_ seen or heard of a language with this model of pointers. Could you give me a reference to such a thing? I would oppose this kind of junk in any case, but it would be interesting to see some language in which people have direct experience with such a badly thought out feature. (I think this whole thing is a clever form of revenge for the bad public review last time.) > ...] > In summary, the uses and description of pointers are consistent as proposed; > it may not fit some notions of what people have thought of as pointers. In summary, recursive data structures and array section aliasing are two _separate_ and _distinct_ activities. In fact, it's hard to imagine using the same pointer to do both of these in the same code! (And, if this does happen, it's probably an unintended and hard to find error.) As a result, they should have separate and distinct implementation in a programming language - preferably _without_ using pointers for either feature.
brainerd@unmvax.unm.edu (Walt Brainerd) (06/17/89)
In article <13941@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <150@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): > > [...] > > If you think of a pointer as just an ADDRESS > > (possibly one that can be incremented and multiplied by 7, etc.), > > (this sort of thing certainly has occurred in Fortran implementions) > > then the proposed Fortran pointers do not fit with that model. > > [... > > That is _exactly_ the model of pointers I have in mind (with the addition of > typed pointers so static type checking of the pointee is possible). Then it is not incomplete semantics or whatever; it is just a simple disagreement on what the pointer facililty ought to be, if any. Discussion with X3J3 members, rational discussion of the tecnical issues in this forum, and comments during the public review are all good ways to try to change things, but the following doesn't help much. At least 2/3 of X3J3 members voted the current model over the other--that does not mean they are right or that they cannot be conviced otherwise. It does mean (by the rules imposed on X3J3 from above) that it takes another 2/3 vote to change or remove the feature. > (I think this whole thing is a clever form of revenge for the bad public > review last time.) Walt Brainerd Unicomp, Inc. brainerd@unmvax.unm.edu
brainerd@unmvax.unm.edu (Walt Brainerd) (06/17/89)
In article <2724@elxsi.UUCP>, corbett@beatnix.UUCP (Bob Corbett) writes: > > One feature of Fortran 8x I find particularly annoying is that the type > definition facility permits only record types to be defined. > It also does not permit structures to be declared _without_ using a type definition (maybe not as important, but certainly a reasonable thing to do). Most members of X3J3 have these two concepts so tightly bound in their minds that they will not even recognize this as a problem. Also the document has the concepts of user-defined typed and structures (record structures) completely confused. I have been trying to convince them to at least make the extension proposed by Corbett a reasonable one and, though some claim otherwise, I feel this is not done in the current propsal. If others out there sympathize with what Bob Corbett is saying, please let yourself be heard! Keep them cards and letters coming, folks! Walt Brainerd Unicomp, Inc. brainerd@unmvax.unm.edu
charlie@mica.stat.washington.edu (Charlie Geyer) (06/18/89)
In article <150@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: > If you think of a pointer as a POINTER (pointing to, referencing, or aliasing > another object), then all uses of pointers in the proposed Fortran standard > fit within this notion (including "traditional" uses of pointers > to implement linked lists and other data structures). > In summary, the uses and description of pointers are consistent as proposed; > it may not fit some notions of what people have thought of as pointers. In article <13941@lanl.gov> jlg@lanl.gov (Jim Giles) replies: > I have _never_ seen or heard of a language with this model of pointers. > Could you give me a reference to such a thing? I would oppose this kind > of junk in any case, but it would be interesting to see some language in > which people have direct experience with such a badly thought out feature. How about C? C pointers point to objects. Pointers that actually happen to point to the same storage location are not required to compare equal and so forth. Just out of curiosity, why is this "junk"?
maine@altair.dfrf.nasa.gov (Richard Maine) (06/18/89)
jlg@lanl.gov writes: >From article <150@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd): >> If you think of a pointer as just an ADDRESS >> then the proposed Fortran pointers do not fit with that model. >That is _exactly_ the model of pointers I have in mind (with the addition of >typed pointers so static type checking of the pointee is possible). >> If you think of a pointer as a POINTER (pointing to, referencing, or aliasing >> another object), then all uses of pointers in the proposed Fortran standard >> fit within this notion (including "tradidional" uses of pointers >> to implement linked lists and other data structures). >> ... >> In summary, the uses and description of pointers are consistent as proposed; >> it may not fit some notions of what people have thought of as pointers. >In summary, recursive data structures and array section aliasing are two >_separate_ and _distinct_ activities. In fact, it's hard to imagine using >the same pointer to do both of these in the same code! (And, if this does >happen, it's probably an unintended and hard to find error.) As a result, >they should have separate and distinct implementation in a programming >language - preferably _without_ using pointers for either feature. But array sections and related concepts are not just an isolated feature of 8x. They are so ingrained throughout the whole 8x standard that it is difficult to imagine a pointer implementation that did not take it into account. Virtually everything else does. For instance, how can I point to a vector formal argument with a pointer that is just an address? There is no guarantee that the elements of this vector are contiguous in memory. The 8x language in general is making a major move away from assuming things about memory layout. This tone permeates the entire standard (and is the source of plenty of complaints from those who like (need?) to diddle extensively with addressing at a low level). The idea of a pointer that is nothing but an address is antithical to this tone. As for examples of languages that incorporate such "strange" notions, how about ANSI Fortran 77? Pointers? In ANSI Fortran 77? Well, not exactly, but consider formal subroutine arguments. Although they don't go by quite the same name, they are closely related (note the simillarity of terminology in the formal words of the standard). The formal parameter does "point" to an actual parameter. Most Fortran 77 formal parameters do consist of just addresses. But not for character parameters. I would argue that character formal subroutine parameters in FORTRAN 77 constitute an admittedly limited but relevant example of this kind of construct. And, of course, if you let me cite 8x then many more cases of formal argument passing are like this. Richard Maine maine@elxsi.dfrf.nasa.gov (don't try to send to me @altair.dfrf.nasa.gov as it won't get through). -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1] (Outside mail won't get to altair.dfrf.nasa.gov, so don't bother trying).
jlg@lanl.gov (Jim Giles) (06/19/89)
From article <1527@uw-entropy.ms.washington.edu>, by charlie@mica.stat.washington.edu (Charlie Geyer): > [...] > How about C? C pointers point to objects. Pointers that actually > happen to point to the same storage location are not required to > compare equal and so forth. C pointers point to _contiguous_ objects - not to arbitrary ones. Therefore, C pointers are just raw addresses (possibly scaled by some type factor). This is _not_ the model of pointers that I object to (aside from a generl aversion to pointers themselves). > Just out of curiosity, why is this "junk"? You have answered part of that yourself. Pointers to the same location don't compare equal. This makes it hard to implement even run-time tests for aliasing (in case you want to avoid it for optimization purposes). Pointing to arbitrary, non-contiguous, objects would only aggravate this problem (along with others concerning optimization). Higher-level constructs are better - _not_ because they are more powerful, but because they are less so. They apply additional semantic constraints on how the constructs work which are useful to both the programmer and the compiler in producing optimal and correct code.
bobal@microsoft.UUCP (Bob Allison) (06/20/89)
In article <2724@elxsi.UUCP> uunet!elxsi!corbett (Bob Corbett) writes: > > One feature of Fortran 8x I find particularly annoying is that the type >definition facility permits only record types to be defined. The lack of a >general type definition mechanism becomes even more irritating now that KIND >selectors have been added to the language. Suppose a machine supports 64-bit >integers. The Fortran 8x implementation for such a machine might permit >64-bit integer entities to be declared with a syntax such as > > INTEGER(64) :: entity-decl-list > >The number 64 is the kind selector. Suppose a programmer is trying to write >a program for several different machines, and he or she has lots of data >object declarations for objects he or she wishes to be of the largest supported >integer type. If the language supported a general type definition facility, he >or she could place a definition of a type, say LONGEST_INT, in an INCLUDE file, >and then use that type wherever it is needed. The closest the current draft of >the standard will allow him or her to come to that solution is to allow a >definition of a structure containing a single field of the longest integer type > [...] It turns out this is easily solvable: the kind parameter may be a parameter (that is, a symbolic constant): INTEGER, PARAMETER :: MOST_INT_BITS = 64 INTEGER(MOST_INT_BITS) :: entity-decl-list However, it doesn't allow you to define a type, merely a type kind. My personal resistance to that feature (contrary to Walt Brainerd's assertion that we're all morons who can't handle the concept) is that it doesn't mesh well with the current rules of FORTRAN syntax: if we could define the first token in each statement of an explicitle separated declaration section to be a reserved keyword or a type (as in other languages which support this feature), then I wouldn't have any problem. However, FORTRAN has enough areas already where the context just takes too long to resolve, and I am reticent to introduce more areas. > > KIND selectors are an inherently implementation-dependent feature. I have > [...] I can easily imagine > > INTEGER(8) > >meaning an 8-bit integer in one implementation, a 48-bit integer in another, >and a 64-bit integer in another. The requirement should be strengthened to be >the capability to detect and report all uses of KIND selectors. > > [...] > Yours very truly, > Bob Corbett This is an entirely separate problem, and a fundamental weakness in the KIND specifier: what does it mean? Not only is it implementation dependent, but it is in units that are implementation dependent. In other words, you are best served by always using symbolic constants whenever using KIND parameters (which almost defeats their use). It can be argued that this is actually an aid to portability since it isolates system-dependent parameters, and I admit to being on the fence for this argument. However, it introduces yet another need for MODULEs (since that is the obvious place to put the declarations), which have become the catch-all bucket for anything and everything. Unfortunately, the source of a MODULE is not necessarily lying around while you're trying to hand- check the code. Bob Allison uunet!microsoft!bobal
charlie@mica.stat.washington.edu (Charlie Geyer) (06/20/89)
In article <13946@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1527@uw-entropy.ms.washington.edu>, by >charlie@mica.stat.washington.edu (Charlie Geyer): >> [...] >> How about C? C pointers point to objects. Pointers that actually >> happen to point to the same storage location are not required to >> compare equal and so forth. > >C pointers point to _contiguous_ objects - not to arbitrary ones. Therefore, >C pointers are just raw addresses (possibly scaled by some type factor). >This is _not_ the model of pointers that I object to (aside from a generl >aversion to pointers themselves). Not so. As I said, C pointers point to objects, not to arrays of contiguous objects. It is true that if p is a pointer to an object, p+1, p+2, ..., and p-1, p-2, ..., may perhaps be valid pointers to objects of the same type. This decidedly does not make them "raw addresses (possibly scaled by some type factor)", as you seem to recognize below. But there is something even more wrong here. Any C object can be pointed to by a pointer. The reason there are no C pointers to array sections in C is that "array section" is not a C object. This is not a limitation on the notion of "pointer" in C, but on the notion of "array", which is extremely primitive in C. Pointers, on the other hand, are completely general. >> Just out of curiosity, why is this "junk"? > >You have answered part of that yourself. Pointers to the same location >don't compare equal. This makes it hard to implement even run-time tests >for aliasing (in case you want to avoid it for optimization purposes). >Pointing to arbitrary, non-contiguous, objects would only aggravate this >problem (along with others concerning optimization). This seems to say that, contrary to what you said above, you _do_ object to C pointers because "pointers to the same location don't [necessarily] compare equal". This is not necessarily a bad thing, as was explained at great length by many posters (none of them me) in a recent flame war in comp.lang.c. The characteristic of a high level language is that is has abstractions -- it isn't raw assembly. And pointers in C are such an abstraction. >Higher-level constructs are better - _not_ because they are more powerful, >but because they are less so. They apply additional semantic constraints >on how the constructs work which are useful to both the programmer and >the compiler in producing optimal and correct code. I don't necessarily disagree. In fact I just made an argument of this kind in favor of pointers that have "additional semantic constraints" over and above "raw addresses". The question to you now is: Why do you think this kind of abstraction is wrong and what kind of abstraction -- raw addresses aren't -- is the right one?
jlg@lanl.gov (Jim Giles) (06/20/89)
From article <1536@uw-entropy.ms.washington.edu>, by charlie@mica.stat.washington.edu (Charlie Geyer): > [...] > The question to you now is: Why do you think this kind of abstraction is > wrong and what kind of abstraction -- raw addresses aren't -- is the > right one? I have already answered this is previous postings. Pointers are a bad idea because they put too much functionality into a single construct. In this regard they are rather like GOTOs (in fact, when comparing control flow with data structuring, GOTOs are isomorphic to pointers). To be sure, you can code any control flow you want using only conditional jumps (even procedure calls) - but do you _want_ to? The reason we have IF-THEN-ELSE, DO, CASE, etc. is to provide the specific functionality required and no more. This simplifies the task of both the programmer and the compiler in producing correct and efficient code. Now, clearly you can define any data structure you want using pointers. But, again, do you want to? Consider the following examples: Old Fortran 8x New Fortran 8x REAL, RANGE :: A(100) REAL TARGET:: A(100),B(98) REAL, RANGE :: B(98) REAL POINTER :: X(:) ... ... SET RANGE (A(2:99)) X => A(2:99) ... ... 100 B=A 100 B=X ... ... (I don't have the 8x proposals with me, so the syntax here may be a little off. But the idea is clear.) In both these examples, the assignment at label 100 can be done at optimal speed since the objects are not aliased. But the question is: can your compiler recognize that B is not aliased to the other? For the old 8x proposal, even a really dumb compiler can tell the assignment is safe. The reason is that RANGE _CAN'T_ cause aliasing! RANGE simply restricts the active elements of the underlying array. In the new 8x proposal, the compiler must do some flow control to make sure that no pointer assignment to X can have caused aliasing to B. If the compiler is not that smart, it must generate code which assumes that B and X are aliased. Consider next a case where aliasing occurs: Old Fortran 8x New Fortran 8x REAL A(100),B(98) REAL TARGET :: A(100),B(98) ... REAL POINTER :: X(:) ... ... IDENTIFY (X(I)=A(I+1),I=1,98) X => A(2:99) ... ... CALL SUB1(X,B) CALL SUB1(X,B) ... ... 100 B=X 100 B=X ... ... Once again. the assignment at label 100 is safe, B is not aliased to X. The question, again, is: can your compiler detect that it's safe to optimize the assignment? By the standards of the first example, the compiler must be reasonably smart in both proposals. Still, flow analysis will detect that it's safe for the old 8x proposal. In the new proposal, the compiler can't tell whether X is aliased to B without doing interprocedural analysis - the subroutine call _COULD_ have reassigned X. The old proposal gave the programmer the tools to define array sections as required - but _NOTHING_ else. Neither the programmer nor the compiler needs to take into account functionality that isn't needed. I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning than the present POINTER proposal is. For recursive data structures I think that they should be provided as just that: recursive structures without explicit pointers required. Aside from these, I can't think of any other need for pointers. I think that Fortran should not have pointers introduced.
khb@chiba.Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (06/21/89)
In article <13949@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > ... stuff about the old f8x vs the new f8x deleted > >I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning >than the present POINTER proposal is. For recursive data structures >I think that they should be provided as just that: recursive structures >without explicit pointers required. Aside from these, I can't think >of any other need for pointers. I think that Fortran should not have >pointers introduced. Many agreed; otherwise "old" f8x would have had them. Unfortunately public comment from bot the US and Europe was militantly for pointers. While it would have been possible to have both sets of features, SET RANGE and friends were sacrified on the altar of simpiler is better ... Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
jlg@lanl.gov (Jim Giles) (06/21/89)
From article <111223@sun.Eng.Sun.COM>, by khb@chiba.Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS): > Many agreed; otherwise "old" f8x would have had them. Unfortunately > public comment from bot the US and Europe was militantly for pointers. > While it would have been possible to have both sets of features, SET > RANGE and friends were sacrified on the altar of simpiler is better ... You have again missed my point. SET RANGE _IS_ simpler!! Furthermore, I don't believe the public comment was all that militant. I really believe that if the public knew what the committee would do with pointers, no one would have recommended them. For example, here's the part of _my_ public review comment pertaining to pointers: Pointers are needed for many applications. Although ALLOCATE and DEALLOCATE serve most of the necessary functionality, linked lists and other indirect referencing schemes are still left out. As can be seen, my concern was mainly for the omission of recursive data types. If I had known what the committee would do with pointers, I would have specifically congratulated them for leaving pointers out. I would prefer to do without recursive data structures rather than have the present pointer proposal approved. As it is, I'm sure that my comment above was incorrectly counted amongst the "militant" support for pointers.
charlie@mica.stat.washington.edu (Charlie Geyer) (06/21/89)
In article <13949@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > Pointers are a bad idea because they put too much functionality into > a single construct. In this regard they are rather like GOTOs. I can't disagree with this. Pointers are medium level, not high level, constructs, much like GOTOs. > I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning > than the present POINTER proposal is. For recursive data structures > I think that they should be provided as just that: recursive structures > without explicit pointers required. Aside from these, I can't think > of any other need for pointers. I think that Fortran should not have > pointers introduced. I won't argue with this either. I'm not sure it's right, but it's a reasonable opinion. I never would have made any argument if you'd posted this in the first place.
chris@mimsy.UUCP (Chris Torek) (06/23/89)
[another `usa' distribution bites the dust] In article <13949@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [paraphrased:] Pointers are to data flow as `goto' is to control flow. (A very reasonable analogy. Many compilers reduce all `high level' control constructs to gotos, then rebuild the high level constructs in order to do control flow analysis, which is a necessary precursor to data flow analysis. Data flow analysis is a sufficiently harder problem to preclude this approach, as yet.) >I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning >than the present POINTER proposal is. For recursive data structures >I think that they should be provided as just that: recursive structures >without explicit pointers required. Aside from these, I can't think >of any other need for pointers. I think that Fortran should not have >pointers introduced. Well said. The problem---and one should understand here that I am not really arguing for one standard over the other: I think either one would be premature---is this: When designing a new language, it is very hard to forsee what will be needed, what will be wanted, and what will simply be excess baggage. Both Pascal and C have `high level' control flow constructs (while, etc). But both also have `goto'. (C has a weak syntatic form; the nonlocal goto is done as a library routine.) The goto---even the nasty nonlocal form---turns out to be good for rare but important things like exception handling. Now, one can always design a new language that includes exceptions, but it happens to be a good thing that no one standardised the `goto-less' form before effectively forcing people to write in an incomplete language. It is unfortunate that they did standardise Pascal (e.g.) before noting the need for conformant arrays. Or, again in re C: before V7, C did not have the `long' data type, nor did it have `union'. They were not necessary, in that they could be done with `struct', but they did turn out to be convenient. Applied to F8x, this might tempt one to throw in both forms: RANGE, IDENTIFY, and recursive data structures; *and* POINTER. This is a tempting road, but at its end lies something worse than PL/I. The art of language design lies in choosing the proper balance of power and economy. I, for one, do not believe that this line can be drawn politically. I am not even sure it can be drawn technically ---certainly not now, and not for the forseeable future. (By `technically' I mean quantitative analysis of the interactions of various language features, as opposed to `gut feel' and/or experimentation.) All of this is why I always fear for the outcome of any ANSI or ISO `standardisation'---all the more so when the `standard' comes to inventing a new language. (If you do not believe the F8x committee is inventing a new language, well, never mind. All language features interact: sometimes very little, but sometimes very subtly. Even the tiniest change may have a large effect.) In short: if you think your solution is best, build it yourself; use it yourself; give it to your friends and neighbours. If it catches on, then---and only then---should you raise the `standards' standard and march off to war. (Well, political war anyway :-) .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
chidsey@smoke.BRL.MIL (Irving Chidsey ) (06/23/89)
Chris Torek's suggestion for build it your self, try it it your self, then sell it your self changes to Fortran, or any other language, sound too reasonable to ever be accepted. Sigh! Irv -- I do not have signature authority. I am not authorized to sign anything. I am not authorized to commit the BRL, the DOA, the DOD, or the US Government to anything, not even by implication. Irving L. Chidsey <chidsey@brl.mil>
mccalpin@masig1.ocean.fsu.edu (John D. McCalpin) (06/28/89)
In an earlier article, Bob Allison quotes Bob Corbett: >> >> KIND selectors are an inherently implementation-dependent feature. >> [...] I can easily imagine >> INTEGER(8) >>meaning an 8-bit integer in one implementation, a 48-bit integer in another, >>and a 64-bit integer in another. The requirement should be strengthened to >>be the capability to detect and report all uses of KIND selectors. > Bob Corbett Bob Allison replies: > >This is an entirely separate problem, and a fundamental weakness in the >KIND specifier: what does it mean? Not only is it implementation dependent, >but it is in units that are implementation dependent. In other words, >you are best served by always using symbolic constants whenever using >KIND parameters (which almost defeats their use). I have found this to be perhaps the most ridiculous "feature" of the new draft. The fact that the _values_ of the KIND selectors are implementation dependent is just *begging* for people to write non-portable code. If the programmer uses long, explicit names for these integer types, then the resulting code would be almost unreadable. For example, suppose that the machine supports a floating-point precision which is less than the default precision (a la Cyber 205). Then the "correct" specification of an operation would be something like: INTEGER, PARAMETER:: HALF_PRECISION=SELECTED_REAL_KIND(5,30) REAL, ARRAY(100), KIND=HALF_PRECISION:: A,B,C A = B + 2.0_HALF_PRECISION*C ! the constant must be half-precision ! to prevent unwanted conversion ! of everything to default real. Is anyone really going to write code like this? Of course, even the non-portable version is almost unintelligible: REAL, ARRAY(100), KIND=1:: A,B,C A = B + 2.0_1*C I certainly don't want to have to *read* code that has this sort of gibberish scattered throughout.... Finally, of course, there is the most general and correct approach: INTEGER, PARAMETER:: HALF_PRECISION=SELECTED_REAL_KIND(5,30) REAL, ARRAY(100), KIND=HALF_PRECISION:: A,B,C REAL, PARAMETER, KIND=HALF_PRECISION:: TWO=2.0 ! implied conversion A = B + TWO*C ! finally, I get to do some calculations! I'm still waiting for the committee's response to my suggestion that an option be provided to specify the default precision of literal constants. -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu
brainerd@unmvax.unm.edu (Walt Brainerd) (07/01/89)
In article <6105@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: > In article <2724@elxsi.UUCP> uunet!elxsi!corbett (Bob Corbett) writes: > > > > One feature of Fortran 8x I find particularly annoying is that the type > >definition facility permits only record types to be defined. The lack of a > >general type definition mechanism becomes even more irritating now that KIND > >selectors have been added to the language. Suppose a machine supports 64-bit > >integers. The Fortran 8x implementation for such a machine might permit > >64-bit integer entities to be declared with a syntax such as > > > > INTEGER(64) :: entity-decl-list > > > >The number 64 is the kind selector. Suppose a programmer is trying to write > >a program for several different machines, and he or she has lots of data > >object declarations for objects he or she wishes to be of the largest supported > >integer type. If the language supported a general type definition facility, he > >or she could place a definition of a type, say LONGEST_INT, in an INCLUDE file, > >and then use that type wherever it is needed. The closest the current draft of > >the standard will allow him or her to come to that solution is to allow a > >definition of a structure containing a single field of the longest integer type > > [...] > > It turns out this is easily solvable: the kind parameter may be a parameter > (that is, a symbolic constant): > > INTEGER, PARAMETER :: MOST_INT_BITS = 64 > INTEGER(MOST_INT_BITS) :: entity-decl-list > The request was for a user-defined type that does not involve structures. What do parameters have to do with anything? > However, it doesn't allow you to define a type, merely a type kind. My > personal resistance to that feature (contrary to Walt Brainerd's assertion > that we're all morons who can't handle the concept) is that it doesn't mesh ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > well with the current rules of FORTRAN syntax: if we could define the first > token in each statement of an explicitle separated declaration section to > be a reserved keyword or a type (as in other languages which support this > feature), then I wouldn't have any problem. However, FORTRAN has enough > areas already where the context just takes too long to resolve, and I am > reticent to introduce more areas. > The evidence for my alleged implication is mounting! (or maybe it's just me) but I don't understand what the first token of a statement has to do with anything, either. What I think is being requested is the ability to do something like this (all statements begin with a keyword): TYPE LONGEST_INT INTEGER(64) ! with or without a paramter END TYPE LONGEST_INT and then be able to declare TYPE (LONGEST_INT) :: entity-decl-list Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
bobal@microsoft.UUCP (Bob Allison) (07/06/89)
In article <193@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes: >In article <6105@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: >> In article <2724@elxsi.UUCP> uunet!elxsi!corbett (Bob Corbett) writes: >> > >> > [...] >> > INTEGER(64) :: entity-decl-list >> > [... but this solution is nasty since the parameter varies ...] >> It turns out this is easily solvable: the kind parameter may be a parameter >> (that is, a symbolic constant): >> >> INTEGER, PARAMETER :: MOST_INT_BITS = 64 >> INTEGER(MOST_INT_BITS) :: entity-decl-list >> >The request was for a user-defined type that does not involve structures. >What do parameters have to do with anything? > It was simply a way of solving his described problem; I do go on to say it doesn't provide a solution via the mechanism he would prefer: >> However, it doesn't allow you to define a type, merely a type kind. My >> personal resistance to that feature (contrary to Walt Brainerd's assertion >> that we're all morons who can't handle the concept) is that it doesn't mesh > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> well with the current rules of FORTRAN syntax: if we could define the first >> [...] >> >The evidence for my alleged implication is mounting! >(or maybe it's just me) but I don't understand what the first token of a >statement has to do with anything, either. What I think is being requested >is the ability to do something like this (all statements begin with >a keyword): > >TYPE LONGEST_INT >INTEGER(64) ! with or without a paramter >END TYPE LONGEST_INT > >and then be able to declare > >TYPE (LONGEST_INT) :: entity-decl-list > >Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu Well, I thought the discussion was about how user-defined types should be able to be declared just like intrinsic types are, so that your last line would be: LONGEST_INT [[attribute-list] ::] entity-decl-list (which could potentially come out as: LONGEST_INT A,B,C which would be pretty tough to parse in the old source form) which was where my point about tokens was aimed. In the example you provide above, I am still somewhat unhappy, because it is impossible to decide if the line "INTEGER(64)..." has a syntax error or not until later in the game (I guess I'm assuming that the type may only have one entry if the entry is unnamed, etc.). Syntactically, this problem is very difficult to solve, and I don't think I've ever seen a proposal which fits well with current FORTRAN syntax conventions. I'd like to believe I've always been open to proposals in this area; I just don't believe I've ever seen one which fits given current syntax conventions. Also, I agree that Walt never explicitly called anyone a moron (after all, if he had I would have put it in quotes ;-); that was my personal interpretation of some comments he made in prior (and current) notes. Finally, let me second Walt's point about providing positive as well as negative comments on the draft during public review. It is as important to know what went right as it is to know what went wrong (it lets us know areas which should NOT be changed). Bob Allison uunet!microsoft!bobal
brainerd@unmvax.unm.edu (Walt Brainerd) (07/06/89)
In article <6234@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: > >statement has to do with anything, either. What I think is being requested > >is the ability to do something like this (all statements begin with > >a keyword): > > > >TYPE LONGEST_INT > >INTEGER(64) ! with or without a paramter > >END TYPE LONGEST_INT > > > >and then be able to declare > > > >TYPE (LONGEST_INT) :: entity-decl-list > > > >Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu > > Well, I thought the discussion was about how user-defined types should be > able to be declared just like intrinsic types are, so that your last line > would be: > > LONGEST_INT [[attribute-list] ::] entity-decl-list Yes, I agree there would be syntactic problems with this form. Lawrie Schoenfelder (X3J3 member from Liverpool) has given some of his reasons why he would not like to have the sort of typing I illustrated above. I think they are valid. Basically, they are that operations on new types should not be inherited from the components. In the example above, that's exactly what you want to do (have +. *, etc. available for the new LONGEST_INT type). But what if the new types are physics quantities like mass, time, etc. that are real numbers, but shouldn't be arbitrarily multiplied by any old real numbers? With the currently proposed scheme, the only inherited operations are assignment and component selection because each type must be a structure and those are the only intrinsic operations on structures. You can still do something like MASS % VALUE * TIME % VALUE to multiply strange things together, but the "%VALUE" does give some indication that something strange is going on. Also, Lawrie rightly believes that most of the production of new types should go on inside modules; here it possible to make access to components private, even to a program that used the type definition, so this forces the programmer using the new type to do all computations with the new type via the operations provided for values of that type in the module. Now I'm not sure what I think of all this. More opinions would be interesting. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
hallidayd@yvax.byu.edu (07/08/89)
Walt Brainerd (brainerd@unmvax.unm.edu) in message <201@unmvax.unm.edu> writes >In article <6234@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes: >> ... >> LONGEST_INT [[attribute-list] ::] entity-decl-list > >Yes, I agree there would be syntactic problems with this form. I would like to see intrinsic_type [[attribute-list] ::] entity-decl-list and user_type [attribute-list] :: entity-decl-list Thus eliminating the need for the TYPE(user_type_name) construct, while not having the syntactic problems inherent in using user defined types in old FORTRAN declaration statements. (A point I have made in several other postings to this news group.) > >Lawrie Schoenfelder (X3J3 member from Liverpool) has given some of his >reasons why he would not like to have the sort of typing I illustrated >above. I think they are valid. Basically, they are that operations >on new types should not be inherited from the components. In the example >above, that's exactly what you want to do (have +. *, etc. available >for the new LONGEST_INT type). But what if the new types are physics >quantities like mass, time, etc. that are real numbers, but shouldn't >be arbitrarily multiplied by any old real numbers? With the currently >proposed scheme, the only inherited operations are assignment and >component selection because each type must be a structure and those >are the only intrinsic operations on structures. You can still >do something like MASS % VALUE * TIME % VALUE to multiply strange >things together, but the "%VALUE" does give some indication that >something strange is going on. Also, Lawrie rightly believes that most >of the production of new types should go on inside modules; here it >possible to make access to components private, even to a program >that used the type definition, so this forces the programmer using >the new type to do all computations with the new type via the operations >provided for values of that type in the module. > >Now I'm not sure what I think of all this. >More opinions would be interesting. I most certainly agree. We, as programmers, should have the ability to appropriately restrict the operations allowed on new data types that are defined, at least those defined within MODULES. The concepts of abstraction and information hiding are long overdue in Fortran. With the ability to abstract and hide information (data structures, types, etc.) we have the ability to provide specialized packages to accomplish specialized tasks, where the ability is retained to update, and completely change, the algorithms and data structures as the need arises, without breaking users code. I have no problem with the restriction this has placed on the definition of data types in the proposed Fortran standard, though this need does not *require* that user defined types be structures and subject to the accompanying restrictions (see the way Ada has such restrictions on PRIVATE types, but not on types that are made public). Along with the ability to _hide_ information, we must also be able to provide the operations the user desires in the most transparent way possible (or the user will object to having the information hidden from his/her view). This is where operator overloading comes in---the ability to define, for instance, a division operator for the cases where such an operation is appropriate (such as dividing a distance type by a time type to yield a velocity type). Furthermore, in order to make such information hiding and abstraction truly useful, we must have the ability to define new sets of types and operations (within a MODULE, usually) which can make use of the types and operations previously defined (usually within another MODULE), without the necessity of having the source code (thus violating information hiding). The ability to have parameterized types does, however, seems to be an appropriate way to have multiple types that share operations (including the ability to pass objects of all such types as arguments to the same procedure, eliminating the need for several copies of the procedure)---in fact, parameterized types provide, IMHO, a clearer indication of the relationship between types that share operations (thus, again, the need for user defined types to be able to have parameters, and perhaps, even defaults for these parameters, so the relationships between user defined types may be just as apparent as for the intrinsic types). _____________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu | | BITNET: hallidayd@byuvax | | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________/