(j3.2006) (j3.2005) Re: Re: question on token replacement/concatenation

[Aleksandar Donev]

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 
Fortran standardization.

> 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 ...
 basic-token basic-token-sequence

There is a blank, even if it is actually a delimiter between tokens and not a 
"blank".

Allowing

MACRO M(X)
X
END MACRO

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:

_ExpandMe(_AnotherMacro)

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:

MACRO M(X)
EXPAND X
END MACRO

> 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
> rules.
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 
issue.

>?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.

Best,
Aleks