(j3.2006) question on token replacement/concatenation

[Aleksandar Donev]

On Monday 04 December 2006 19:17, Malcolm Cohen wrote:

> If you cannot read my message, that would seem to be your problem.
I am not going to spend time on such absurd arguments. Telling me what I think 
or said is hardly a good use of anyone's time...back to technical content.

The kind of restriction in the BNF that I am thinking of is limiting macro 
actual arguments to names, names followed by "(...)", constants, type specs, 
keywords (maybe this is the same as names, but how about "sync all"), and 
expressions (without the typing rules of course). The exact list should be 
thought of, but I believe it ought to be much more restricted than any 
sequence of tokens that has proper delimiter nesting and no commas outside of 
those delimiters, since that includes things like "8 A", "=4", "this is a 
silly macro actual", "allocate(b(1:100))", which I consider bad design. I do 
not want to allow:

expand macro(=4, **6, allocate(b(1:100)), &
 btw don_t use this macro argument other than in present )

in Fortran programs?!?

Here is a very quick (and likely flawed) attempt at the BNF. It should give 
some indication of the direction I think we ought to go toward.

basic-token-sequence is 
 lexical-token-sequence
or [ lexical-token-sequence ] nested-lexical-token-sequence

lexical-token-sequence is
  arg-token [ arg-delimiter arg-token ] ...

arg-token is a lexical token other than delimiters, comma, =, =>, ;, ::

arg-delimiter is comma, %, or =

nested-lexical-token-sequence is
    ( [ lexical-token-sequence ] [ , lexical-token-sequence ] )
or (/ [ lexical-token-sequence ] [ , lexical-token-sequence ]  /)
or lbracket [ lexical-token-sequence ] [ , lexical-token-sequence ]  rbracket

Best,
Aleks