J3/02-186 Date: 29 April 2002 To: J3 From: Kurt W. Hirchert Subject: Possible changes to SELECT TYPE syntax =========== Suggestions =========== The suggestions below are not intended to change the capabilities of the language. It is hoped that they might make the language easier to read. 1. Change the syntax of the from END SELECT [] to END SELECT [TYPE] [] and make a similar change to the (i.e., the terminal statement in a ). In most cases, saying END SELECT TYPE and END SELECT CASE should be clearer than just saying END SELECT. If a programmer is perverse enough to use a of CASE on a SELECT TYPE construct or TYPE on a CASE construct, the result can look surprising to a human reader, but it shouldn't confuse the compiler. 2. There have been a number of complaints in comp.lang.fortran about the TYPE IN guard. I offer a couple of alternatives: a. Change TYPE IS to TYPE and TYPE IN to CLASS. In other words, use the type declarations themselves as the guards. The one possible complaint about this syntax is that TYPE(type_name) select_construct_name looks to the human reader like a variable declaration rather than a type guard. A compiler would have no trouble with it, as it appears in a different context and the select_construct_name has already been established to have a different local meaning, but since this is normal usage (as opposed the perverse usage in suggestion 1), such potential confusion may be judged unacceptable. b. Leave TYPE IS unchanged, but change TYPE IN to CLASS IS. c. With either of the above two suggestions, there is the question of what to do with the TYPE DEFAULT guard: i. It could be changed to DEFAULT or perhaps DECLARED. (It is selected when we can say nothing more about the dynamic type of the selector than what we know from its declared type.) ii. It could be eliminated. As Note 8.13 points out, it is relatively easy to write a TYPE IN guard which does exactly the same thing. ===== Edits ===== If any of these suggestions receives a favorable response from the committee, I can produce a revision of this paper with edits. ===== Aside ===== The title on section 8.1.5 is wrong. (That fact doesn't really belong in this paper, but I wanted to record it somewhere before I forgot it.) - end -