Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ukma!psuvm.bitnet!psuvmxa!cunyvm!byuvax!hallidayd From: hallidayd@yvax.byu.edu Newsgroups: comp.lang.fortran Subject: Re: Pointer examples and 8x Message-ID: <673hallidayd@yvax.byu.edu> Date: 4 Jul 89 04:50:04 GMT Lines: 104 Walt (brainerd@unmvax.unm.edu, message <194@unmvax.unm.edu>) corrected a few lines of my Fortran code (message <661hallidayd@yvax.byu.edu>), I thank you Walt. However, I have a few comments on the comments (comments concerning the apparent state of the latest proposed standard). >> TYPE (NODE), POINTER FUNCTION INSERT (HEAD, NEWNODE) ! I believe this to > ^^^^^^^^^ Can't put this on function line (irregularity?) Are we allowed to use (note the double colon) TYPE (NODE), POINTER :: FUNCTION ... If not, then I would indeed say we have an irregularity that should be corrected (IMHO). I recognize the need for the double colon to prevent ambiguity, especially in the future when we may allow such attributes as FUNCTION or SUBROUTINE, so I have no problem using it here. (A further note here concerning ambiguities, when the double colon form of declaration is used let's allow the user defined type to be used without the TYPE(user_type_name) construct---in fact, I would not mind if user defined type names are only allowed to be used in the double colon form of declaration statement.) > ... >> >> TYPE (NODE), POINTER :: HEAD, NEWNODE >> TYPE (NODE), POINTER :: PTR >> INTEGER :: NUMBER = NEWNODE % VALUE ! I believe the syntax > ^^^^^^^ > , DATA > ^^^^^^^ Until recently, it was proposed that > you could do this with a DATA attribute; now use the old DATA statement. I very much prefer the DATA attribute, rather than the old style DATA statement. I would much rather see the old style DATA statement put on the Obsolescent Feature list than give up the DATA attribute. (Why are we to be forced to stick with the old ways of FORTRAN simply because that _was_ the way things were done in the past---let Fortran *evolve*, allow us to use improved methods and constructs, *PLEASE*. This is directed as much to users that complain that _new_ Fortran is not _old_ FORTRAN and therefore undesirable, as it is directed at the standards committee. It contains _old_ FORTRAN as a proper subset, and will for at least a decade to come. Why is that not enough????) > ... >> >> PTR => HEAD >> DO, WHILE (ASSOCIATED (PTR % NEXT) .AND. PTR % NEXT % VALUE < NUMBER) >> ! This (and the C code) work >> ! because the .AND. operator >> ! is a "short circuit" form. > ^^^^^^^^^^^^^^^^^^^^^^^^^ >> ! (See Ada for a language that >> ! distinguishes between short >> ! circuiting and non-short >> ! circuiting logical operators.) > >Nope! Fortran says things can be evaluated in any order, so this will >not (necessarily) work if PTR % NEXT is not ASSOCIATED. You are absolutely correct. I forget sometimes because the "short circuit" form for the .AND. and the .OR. is the way all compilers I have used thus far have treated these operators. What we have in FORTRAN is actually something in between the "short circuit" form, and a complete evaluation of logical statements using logical `and' and `or' constructs. I would prefer to be able to choose between full evaluation and "short circuit" forms on a case by case basis, as is available in Ada. This would basically involve the standard designating another set of logical `and' and `or' operators, and indicating that either the new `and' and `or' operators are of the "short circuit" variety and that the old operators are to have all operands evaluated, or, the reverse, have the old .AND. and .OR. defined to be the "short circuit" variety. (Having the old .AND. and .OR. operators defined to have all operands evaluated would be the closest to the present standard though the other choice would be the closest to present, though incorrect, practice.) Maybe, for performance reasons, we should have (yuk?) three types of logical `and' and `or' operators. One acting in the way the present .AND. and .OR. do (retaining their meaning and indeterminacy), another for "short circuit" forms (greater control over what is and what is not evaluated), and the third defined to have all operands fully evaluated. As it is, we can simulate the full evaluation form of logical statements by evaluating all function calls prior to the logical statement, and we can simulate the "short circuit" form by a series of separate conditional statements (which is probably more difficult to optimize than a true "short circuit" form would be, and is certainly more messy). Personally, I could live with the present set of logical operators, defined in their present, indeterminate, way (for performance reasons), if we are given the addition of true "short circuit" logical `and' and `or' operators (recognizing that the control flow nature of the new `and' and `or' operators would make them unable to be overloaded---no problem). I don't remember what the "short circuit" forms are called in Ada (some people would want to stay away from whatever Ada did, but I feel we can learn a few things, including what NOT to do, from Ada), but I feel .AND_THEN. (or .AND_IF.) and .OR_ELSE. may be good names for the "short circuit" form of logical `and' and `or' operators, since only if the left hand operand to the .AND_THEN. is true will we also evaluate the right hand operand to determine the outcome, while if the left hand operand of the .OR_ELSE. operator is true we do not need to (and will not) evaluate the right hand operand. What do others think concerning this? _____________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu | Let Fortran be the BEST it | BITNET: hallidayd@byuvax | can be! | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________/