J3/02-134 Date: 2002 February 16 To: J3 From: Walt Brainerd Subject: Some concerns Here are some things that I have some problems or questions about, but are not proposals at this stage. Maybe somebody with some opinions or knowledge of what has taken place relative to any of these can talk with me at meeting 160. 16:9 says that "the effect of execution is as if ...", but right above it says that execution of a program begins with the first executable construct (no as if). Why is one "as if" and the other not? We need a statement in section 1 that says almost everything must be "as if". 28:2 I think it is true that whenever a keyword is actually two English words, one may put a blank between the words. So I am concerned about TYPEALIAS. I am not sure what to do, because it is bad enough to have two different statements already that begin with "TYPE". However, if it is not syntactically ambiguous, I would like to have an optional space. Or is there another suitable keyword? 45:4.5.1.1 This is very complicated due to the requirement that a kind be defined before used. A function may be typed with a DT that is defined inside the function, so why isn't something similar allowed for kinds? If there is an implementation reason that this is harder for kinds than for types, that might explain it. 122:7.1.8.1 After Note 7.16 at the end of the section, add the text of the Fortran 77 interpretation about side effects as Note 7.17: "Certain side effects are permitted, but the result of using them is not defined, i.e., it is processor-dependent." 124:1 The description of the intrinsic COS says that it resturns an approximation to cos(x). Table 7.2 says that + means to add x1 and x2 (nothing about an approximation). How about a statement in Section 1 that the description real (and complex) operations and functions produce approximations? Then get those words out of the descripton of the intrinsics, so that there is no implicication (however silly and impossible) that addition must be exact. Shorten the standard! 191:9.5.3.7.2 I think DT interfaces should use IOSTAT instead of eof, err, and eor. It should work just like the usual IOSTAT. Here is a wild idea: restore the F95 deleted features and get rid of the obsolesecent concept. It just irritates users and hasn't accomplished its purpose of allowing future compilers to be simpler. In fact, it is surely extra work to check for those two categories of features.