J3/06-277 Date: 10 August 2006 To: J3 From: Dick Hendrickson Subject: macros References: J3/06-007 Questions and comments that are more than editorial limited to the macro facility. I ran a preliminary version of this list by Malcolm. I've left his answers intermixed with the questions. For personal reasons, I'm running out of time and I'd like to be able to meet the "readable on the plane" rule. The e-mail exchange follows. My original questions, etc. are preceded by >>. Malcolm's responses aren't. My response to his is preceded by ?? Dick Hendrickson -------------------------------------------------- Here are some off-the-cuff responses; I might change my mind on some of these after thinking about it more. >> General questions. >> 1) Can a MACRO generate an EXPAND? I don't think it should, but >> I didn't see a constraint against it. Yes, definitely. That is how a macro calls another macro. (We might not have the timing written down rigorously here.) ??I was thinking more of something like a line in a MACRO dummy_arg (list) where sometimes the EXPAND looked like' EXPAND(EXPAND) and other times like EXPAND(CALLSOMETHING) !source form issue here >> 2) Can an INCLUDE appear inside of a macro definition body? I think we have to say Yes. Depending on the technical choices here there might be some considerable work to do. >> If so, is it copied in before or after macro expansion? >> I can see good uses for either choice. We should allow INCLUDE to contain macro constructs. That implies either before, or during. Not after. If during, we need to say explicitly that EXPAND may produce an INCLUDE "statement". Oops - that's not a statement... >> 3) Can an EXPAND generate an INCLUDE? Yes if "during" or "after". ??Again, I mean really generate in the sense that's it's not an INCLUDE until it has been processed. Something like arg_one arg_two and expanded with EXPAND (include, "file") >> 4) Can an EXPAND generate comments? It might not be standard >> conforming, but it is pretty common for compilers to accept >> CDIR$ style compiler directives. These are often system >> dependent, and using a MACRO to choose the right ones seems >> like a logical thing to want. Comments having an effect is an extension to the standard. About all we could do here is to say in our recommendation about a processor producing the "result" of macro expansion that such a result should include the comments. >> 5) Can an INCLUDE bring in MACRO definitions. (I think it >> should, but I didn't see any mention of it. 2) probably >> will answer this one.) Yes. A macro definition is just a normal Fortran declaration. >> 6) There seems to be no discussion of fixed form, and the 33280 >> limit is (I think) a free form thing only. Is the MACRO >> facility expected to work with fixed form? There is no discussion of source form at all (except as motivation for the 33280 limit). It is expected to work in either source form. ?? I think a note would help the fixed form user. >> 7) I don't think either %% or && are defined in bnf, at least not >> like ** is. Does this affect whether or not blanks can appear >> in them? Is % % the same as %%? This might also be a fixed >> form issue. We probably need to add %% and && to the list of tokens, then blanks are not permitted within them (in free form). >> 8) Can macro lines themselves be continued? Is there any possibility >> that the & and && can get confused? Yes. No. >> [10:17] Making macros part of the declaration constructs means >> we can't use them to construct things like implicit >> statements. Should we allow them anywhere and just call >> them a special case? Sure you can. Macro *definitions* are declaration constructs, but macro expansions can occur anywhere the macro is accessible. MODULE my_cute_macros DEFINE MACRO weird_implicits(type1,type2) IMPLICIT type1 (A-H,O-Z), type2 (I-N) END MACRO END ... USE my_cute_macros EXPAND weird_implicits(REAL(KIND=3),INTEGER(KIND=5)) ! produces ! IMPLICIT REAL(KIND=3) (A-H,O-Z) INTEGER(KIND=5) (I-N) ?? I was thinking of a local macro that can't be locally defined before the implicits. It just seems odd to me that some macros can't be defined where they will be used. I don't feel strongly about this. >> [14:1] I'd add EXPAND and (maybe INCLUDE) to this paragraph. >> Copy sentences starting at [11:52], but don't tell >> Dick Weaver. INCLUDE is not a Fortran statement. (That's what it says.) I agree on EXPAND (with the current formulation). An alternative would be to make EXPAND "not a Fortran statement", even though it looks like one. >> [14:table 2.1] Need macro-decl in list Yes. >> [14:table 2.1] Need BLOCK in the header line OK. >> [14:19] Again, I'd add EXPAND and INCLUDE to the laundry list. Not INCLUDE, unless it gets reclassified as a statement. >> [15:table 2.2] Should macro-defs be added to the misc list? Sure, or delete 2.2. ??An alternative would be to make it a note. It's handy to not have to read the BNF to get the gist. >> [15:table 2.2] Add a column for the new BLOCK block, it's an >> interesting new scoping unit BLOCK is not a scoping unit, so no. Anyway, I would prefer to delete the table since it is duplicative. ??An alternative would to make it a note. ??Yes, but. 191:27 talks about entities "whose scope is that of the block". It sort of acts like a scoping unit. >> [25:3] Macros should be added to the list Editorially, I intend to do [25:1] Change clause title to "Lexical tokens, source form, and macro processing" (If that's too long, just "macros" at the end. Or "Characters, tokens, source form, and macros"?) {Should mention macros in the title!} [25:2-3] Delete. These lines are not ISO conformant. {The presence of these lines makes a reference to clause 3 ambiguous - does it mean everything up to 3.1, or everything up to 4. That is why ISO do not allow that. Yes, there are lots of other examples (not in new text, since I've been fixing it as I've been going), and those are going to be changed too.} so I wouldn't bother fixing the witter if I were you. >> [30:2+] Need to add END MACRO, MACRO END IF, etc to the list Only if we want to allow them to be written as ENDMACRO and MACROENDIF. I'm not to bothered about END MACRO, but I dislike MACROENDIF and MACROIF. ??OK, I give. I was reasoning by analogy, not thinking hard. >> [33:30] Change "the specified type" to "integer type with the >> specified kind" Hmm, maybe just change "the specified type" to "type integer". The next sentence handles the kind ok. I think. Since this isn't a , it doesn't have the semantics of specifying a type and kind in the usual way. So we have to be a bit careful. >> [34:4] I don't understand C309. Would it be more clear without >> the double negative? I don't think it wouldn't be less clear. "In a macro definition, an , , or shall not appear on a line with any other statement." I prefer the original as being more future-proof, but maybe this is easier to read? >> [35:20] The 33280 should include both inter-token spacing and >> any necessary & continuation characters. No, the 33280 already has the continuation characters subtracted. 130 = 132 minus initial and final continuation characters. 33280 = 256*130. Re fixed form: with this formulation it is possible for a macro to generate code which is longer than the maximum statement length. That is not a problem unless you implement it as a preprocessor without any compiler option to accept mega-long statements. >> [35:20] I think this means the macro expander manages both >> between token blanks and continuation markers. A >> note saying this would be helpful. No, the user manages between-token blanks. The macro expander only handles the continuation markers. Except, of course, that it doesn't. It just feeds the internal form of the tokens directly into the phase of the compiler following initial tokenisation. >> [35:note 3.11] What happens if the compile mode is fixed form? Fine. Not a problem - it is still valid. What might not be valid is taking the output from "displaying the results of macro expansion" (assuming the processor has that capability), and feeding it back in as fixed form source. The note is just explaining the rationale for the limit (any compiler has to accept statements that long). The rationale is not "so you can feed the output from macro processing into the compiler", it is "don't make the compiler have to work harder than we did already". If you want the rationale to be the first, change the limit from 256*130 to 256*66. >> [36:21] This says (via R344) that a macro argument is >> a basic token Well, a basic token sequence, not necessarily just one. >> and that a basic token is "any lexical >> token except...". [26:16] says >>lexical tokens<< are >> "keywords, names,...". None of the list members really >> match what we want for macros. The closest match looks >> like "name" If I do something >> EXPAND some_macro (FRED, fred) >> what are they the name of? Are they the same name? Sure they are the same name, courtesy of 3.1.1. >> [36:21] If the EXPAND arguments are visable to the host, does >> implicit apply to them? I don't understand what you are getting at. If you are talking about the macro dummy arguments, of course they are not visible - their scope is that of the macro definition. Just like the dummy arguments of an internal procedure, or the type parameters of a type definition. ??What I had in mind was in EXPAND (FRED) if FRED is a lexical token, as described in [26:16] then it looks to me like it is a name. Nothing else makes sense. So, what is the name of? Would implicit none force FRED to be typed. >> [37:2] Suppose in the body I something like >> NAME % optional_dummy_macro_argument % Z >> and the dummy argument is not PRESENT >> Does it expand to >> NAME%%Z Yes. >> or does concatenation kick in and do I get >> NAMEZ No, because your is | | | | | v v v v v | | | | | v v v v v NAME % optional_d_m_a % Z No concatenation kicks in because you have no %%'s in your . >> The answer might depend on how blanks can or must be >> used and whether or not fixed form source is to be >> supported. Nope. %% and && are in the macro definition, you don't expand them and expand them again (unless, of course, you are producing macro definitions via EXPAND). >> [37:11] The "which" clause appears to be dangling. I think either >> interpretation is OK, but it should probably be fixed. I see only one interpretation... ...how do you get two? ?? The which clause could apply to "Token concatenation" or to "the %% operator". To me eye, the first would allow the %% to appear outside of macros and do something else. >> [37:17] Is the first line the one that prohibits macros from >> producing INCLUDE lines? If so, it should actually say >> it (in my opinion) and also add blank, empty, and comment >> lines to the list. Yes (as it stands). What ?? It's kind of indirect to say "statements" to mean "not INCLUDE or comments or blanks or empty." >> [38:18] What is the scope of a macro produced internally to a macro? >> There was discussion at one of the meetings, and I don't >> remember how it turned out. A macro cannot be produced "internally" to a macro. A macro can produce macro definitions when it is EXPANDed. A macro definition inside another one must (syntactically) be a sequence of s, so it has no semantics until the macro is expanded and the DEFINE MACRO keywords are recognised. That defines the new macro in the scoping unit containing the EXPAND statement. ??OK, I was thinking there was a discussion of somehow having local helper macro's that get redefined each time the outer macro is expanded. Something like a MACRO INTEGER local variable which springs to life each time the macro is expanded and might have a different kind. >> [38:21] It's maybe obvious, but a note saying that any macro that >> produces declaration and executable statements needs a >> BLOCK - END BLOCK construct It's not true. A macro can produce both declarations and executables, bare (or within BLOCK - END BLOCK, or within SUBROUTINE - END, etc.). Such a macro has limits on where it can be used, but that is the case for many macros. As a matter of programming advice, we could say that a macro which needs a local variable "should" use BLOCK-ENDBLOCK, but I don't think that is particularly necessary.