From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 31 08:41:01 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id BFA6735699F; Fri, 31 Aug 2012 08:41:01 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 0A744356877 for ; Fri, 31 Aug 2012 08:40:59 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id q7V6esxC038256 for ; Fri, 31 Aug 2012 06:40:56 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: From: "Malcolm Cohen" To: "sc22wg5" References: <20120804040444.460F63568DA@www.open-std.org><20120806212738.70CE53568F2@www.open-std.org><20120807182349.20E743568F8@www.open-std.org> <20120818115719.C0FDD35691B@www.open-std.org> In-Reply-To: <20120818115719.C0FDD35691B@www.open-std.org> Subject: Comments on comments on Ballot 3 on Fortran 2008 interpretations Date: Fri, 31 Aug 2012 15:40:54 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk re F03/0053. John Reid writes: <<< 1. I remain of the opinion that 15.3.3 should state clearly that C_PTR and C_FUNPTR do not have the BIND attribute. >>> The editor replies: - it is a fundamental principle that entities only have the attributes that the standard says they have. We do not say the integer 13 does not have the BIND attribute. We do not even say that derived types defined with no BIND(C) clause do not have the BIND attribute! We should strenuously resist putting more unnecessary blather into the standard. Oh, and at max this is "friendly witter". Inserting witter is not necessary for defect correction. In fact my opinion is that this kind of thing is not friendly at all but is harmful to comprehension, because it means that in every other case where we don't say an entity "does not have (laundry-list of attributes)", the reader will be misled into thinking that maybe it might. No. No. No. Just don't do it. And especially there is no case for doing it via interp. <<< It is counter- intuitive that they are interoperable and yet do not have the BIND attribute. >>> Not so; plenty of things are interoperable and do not have the BIND attribute. For an example of another type that is interoperable but does not have the BIND attribute, see INTEGER(c_int). <<< They are defined in an intrinsic module so the reader cannot look at the definition. >>> There is, in fact, no derived-type definition, any more than there is a secret INTERFACE block for any generic intrinsic. A derived-type definition is a piece of Fortran syntax in the program, and therefore cannot be exist in anything intrinsic. <<< The present text relies on the distinction between "derived type" in 15.3.3 and "Fortran derived type" in 15.3.4. >>> No it does not. I do not know where this bizarre idea comes from. Nick Maclaren writes: <<< I agree with John Reid that it would be better to state explicitly that they do not have the BIND attribute, but that would not help. Sentences 2 and 3 in 15.3.3 paragraph 2 states that they are interoperable, but sentence 1 of 15.3.4 paragraph states that a derived type is interoperable if and only if the Fortran type has the BIND attribute. >>> No it does not state that. I am boggled by this assertion! p1 says "... is interoperable if it has ..." i.e. It Most Emphatically Does Not Say "ONLY IF". It is p2 that says that a derived type interoperates with a C struct *if and only if* it has the BIND attribute. That means that C_PTR and C_FUNPTR ***CANNOT*** have the BIND attribute, because ***they do not interoperate with any C struct***. Back to John. <<< The term "Fortran derived type" is undefined and is not used anywhere else in the standard (as far as I can see). >>> It is not an undefined term, it is plain English. Grr. I understand why the authors of that text thought it was useful to drop a few "Fortran" hints in case the reader got the idea they might have been using a C term, but IMO it was unnecessary (it has confused John at least!). <<< The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard. In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say that these types do have the BIND attribute. >>> I dispute this account. Though N1622 is ancient history and not relevant anyway. The point is that J3 was confused about whether THEY INTENDED for these types not to have the BIND attribute. There was no confusion in my mind, or likely in other /DATA or /INTEROP members, as to what the standard actually said, the question was entirely whether this was a mistake or not! And if the answer was ever going to be that they had the BIND attribute, of course an edit was needed as you point out, because in the absence of an edit they do NOT have the BIND attribute, any more than 42_c_int does. <<< 2. Was it really intended that a user-defined derived type with the BIND attribute be permitted to have private components? >>> Yes, by analogy with SEQUENCE. In fact BIND is very very like SEQUENCE, the only real difference being a potential difference in alignment padding. <<< It seems to me that this should not be permitted since it destroys the purpose of declaring components to be private. >>> Then we had better prohibit PRIVATE from SEQUENCE types, because it has Precisely The Same Effect there, and has done since 1991. We Are Not Going To Do That. (Aside: we don't even prohibit non-SEQUENCE non-BIND(C) types with PRIVATE components in the TRANSFER intrinsic, so this idea that PRIVATE is some kind of impermeable electric fence has never been correct.) <<< If it was intended, the rationale should be included in the answer - this is, after all, an interpretation. >>> No rationale is required for this any more than for any other part of the standard. It has the normal rationale "it got voted in". You don't get us to write 1000 lines after class if you don't like the answer, that is no more reasonable than it would be for me to demand to hear from you why everyone voted for SEQUENCE+PRIVATE back in the day... J3 has consistently voted against any kind of rationale document. There is no case to answer here. Nick writes: >I also agree with John Reid on question (2), and regard the liberty to >break the privacy restrictions by using interoperability as a defect in >the standard. Well good then, because you cannot "break the privacy restrictions" that way. The user cannot put BIND(C) on the derived types in the library he is calling. If it's his own library, *HE CAN DO ANYTHING HE LIKES ANYWAY*. The Fortran PRIVATE attribute has never ever been this super-restrictive thing that you and John are imagining. For SEQUENCE types (and thus BIND(C) types) there are multiple ways of "seeing past the curtain", in these cases all PRIVATE does is to hide the name when accessing things of the type outside of a module with a definition. This is not as useful as PRIVATE on an extensible type, but still has some uses. Once again, with feeling: BIND(C) is merely the interoperable version of SEQUENCE, and therefore has basically the same allowances and limitations as SEQUENCE. There is no defect here. re F03/0065 David Muxworthy writes: <<< The interpretation hinges on whether 'values' in F2003 section 7.1.8.5 (and hence F2008 7.1.5.5.2) refers to mathematical values or computational values. >>> The clear meaning of "all possible values" is "all values that are possible". Otherwise we'd have simply written "mathematically equivalent" if that is what we meant. I find it somewhat boggling to hear 3 users say that they are happy to get the wrong answer for a relational operator, when no vendors are complaining that their hardware cannot do it fast enough. I used a mini-computer in the 70s that did not have a comparison instruction, but then it did not have multiply, divide, or even subtraction either! But Fortran still required all those to work. These days, even my washing machine has hardware to do a correct comparison! <<< Both F66 (section 6.2 in descriptive English) and F77 (section 6.3.3 explicitly) state that where e1 and e2 are of different arithmetic types, the value of e1 relop e2 is the value of ((e1) - (e2)) relop 0 >>> Sure, but F66 and F77 say *lots* of things that are no longer true. We changed this in F90, that is already over 20 years ago. <<< F90 section 7.1.7.5 states, in normative text: the processor may choose to evaluate the expression I .GT. J where I and J are integer variables, as J - I .LT. 0 and this is repeated as a note in F95 (7.1.7.5) and in F2003 (7.1.8.5). >>> Right, and we removed this erroneous note in F2008 (paper 07-211). <<< this change to the long-established interpretation of mathematical equivalence should be recorded as a change to the language. >>> It is not a "change to the language" to insist that something gives the right answer: it was not forbidden to give the right answer before!. Furthermore, the change occurred in the big rewrite for F90; yes, that left an inconsistency which was finally removed in F2008, but by then it was removing bad advice, nothing more. It is ironic that at least one of the people who would be happy for relational operations to give the wrong answer was also insistent in F2003 that ATAN2 be bit-perfect re negative vs positive zero! Obviously ATAN2 is a function that is *so* much more important to get right than comparison... I agree with Robert Corbett: there is no gain in portability or usability by allowing comparisons to return the wrong answer. We should stick with the text as written. re F03/0084 John Reid writes: <<< The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. >>> No it does not. IEEE peculiarities play no part in the mathematical Reals. IEEE is merely one form of computer arithmetic. (It would make very bad mathematics, since IEEE numbers are not even a subset of the 2-point compactification of the Reals, thus nearly all mathematical identities and theorems about the Reals would get destroyed.) Computer arithmetic is *computational* not *mathematical*. ALL computer arithmetics frequently give different computational answers for mathematically-equivalent expressions. And I cannot believe you are again trotting out this nonsense saying constant expressions should not be treated as constant. If I have "REAL(KIND=INT(a+b)) :: x(INT(a+b)) = a+b; y=a+b", with a and b being floating-point named constants, I am not allowed to evaluate a+b at compile time? Surely you jest. Or I can in the KIND= but not in the array bound? Unless the array is in COMMON or has the SAVE attribute? Surely you jest even more. Or I can everywhere except in the "y ="? You cannot be serious. Furthermore, the rationale you are using is applicable to all routines regardless of whether they call IEEE_SET_ROUNDING and would thereby destroy many basic optimisations. You.Really.Can.Not.Be.Serious. re F03/0121: <<< I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defined, or becomes undefined only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ..."). >>> Well no. Inter-statement optimisation is alive and well (re, in spite of F90/000001: some vendors have to compete on SPEC benchmarks and the like!), and the people moaning about the REAL() intrinsic not doing what they want frequently also want the optimisation cranked up to that level. In that case, VOLATILE is something that does, in fact, work. One might plausibly argue that we are being more helpful here than we need to. Nick opined: <<< is a common myth in among C and C++ and even in informative text in the standards that volatile implies this semantic >>> If informative text in the standard implies this semantic, that is a clear indication of the intent of the C committee. <<< but it is not justified by their normative text, >>> That is your opinion. You might or might not be right. My understanding of the normative text is otherwise i.e. the same as the informative implication. I might or might not be right. Under the circumstances, since this is the Fortran committee not the C committee, we should take the informative text as being correct rather than what some of the barracks-room lawyers say. <<< nor do all compilers support it >>> Many compilers have many bugs in many areas, and volatile is no exception to this. Indeed, papers have been written on such very topics. However, this case is very simple (no multi-threading required!) and in my experience it does work reliably. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.