(j3.2006) (j3.2005) Re: Re: question on token replacement/concatenation
Mon Dec 4 13:25:19 EST 2006
On Sunday 03 December 2006 17:29, Malcolm Cohen wrote:
> ?(a) we didn't put that restriction in;
Which may have been an omission not intended by people other than you. No, I
don't think you ever asked us, or maybe you assumed we got it all from the
bnf. Some of us did not...It is not good that in order for me to discover a
bug in the bnf (as I did in the last meeting) I have to first ask a question
"Is this what we intended?"
> ?(b) I completely and utterly disagree with it.
Good, but saying that did not convince me at all. I still find it a useless
trap that would only make macros harder to debug and use.
> Tokens are ***ALWAYS*** allowed to be
> separated by blanks.
OK, that I will buy. All the more reason not to allow any spaces in the "E" to
subtly change the meaning of 3 %% E %% 0, which is what Mike was suprised
about (as am I).
> > Should we allow a statement such as:
> > DO_THIS
> > to expand to an actual Fortran statement
> Of course, ***THAT IS THE WHOLE POINT***.
The whole point of what?
Why do we have EXPAND then?
In one macro processor I use (FWEB), there is no special "macro expansion". An
X may expand to produce a whole subprogram, half a line, a comma-delimited
sequence, a semicolon, or whatever. That is utter flexibility, and also
utterly uncontrolled. I did not ask for that, nor will I as part of the
> That is totally wrong. ?A macro actual argument value contains no blanks,
> unless as part of a character literal constant.
> That's right, none.
> It is a token sequence. ?Beginning and end of story.
I don't see the point of nitpicking about terminology here.
basic-token-sequence is ...
There is a blank, even if it is actually a delimiter between tokens and not a
EXPAND M(REAL LY)
to declare a real variable LY seems very bad to me. Really hard to read macros
and try to understand what they are trying to do, and to have some control
over what kind of errors can occur during their use. Yes, I know it can be
allowed (it is not a technical problem as allowing comma's would be,
obviously), but that is not the same as it should be allowed. I also
understand that what we do want to allow is:
EXPAND DeclareVariable ( REAL (KIND = 3) )
which merely uses the blanks to make the code more readable. I believe it is
possible to construct bnf that allows the above but does not allow
EXPAND M(REAL LY)
In my example of the macro M above, the fact that you cannot put commas in the
actual is a trap that I have fallen in my own use of macros. If you want to
give an attribute to Y, you are stuck. In my codes, I have a macro _Identity
which merely allows one to include commas in an actual argument:
_ExpandMe(_Identity(REAL, TARGET :: Y))
This only works with FWEB because there expansion of _ExpandMe occurs first,
and then _Identity is expanded. It is very tricky and while flexible, really
hard to use right and get the order of expansions and replacements and
concatenations right. In FWEB I can also do:
and then declare many variables. But with our macrod design, in order to allow
anything but a sequence of tokens for X, one needs to use:
> Not to mention diametrically opposed to the sort of thing you were saying
> when we were actually discussing this stuff, which was to bang on about us
> making it as general as possible and not to put in restrictions and silly
What I was "banging" about was the fundamental(ly wrong) decision to only
allow/work on statement-level macros, and exclude comma-separated sequences.
It had nothing to do with allowing arbitrary token sequences as actual
arguments. I am pretty sure I never expressed any explicit opinion on that
>?You didn't (you
> argued against disallowing commas except within parens in macro actual
> args, which can never work).
I have no idea what you are saying here, so if I said it, it was probably a
misunderstanding on someone's part.
More information about the J3