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

[Aleksandar Donev]

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

> You are really talking about
> ? 3 %% 4 E %% 0
> being different from
> ? 3 %% 4E %% 0
> and that is an entirely different kettle of fish.
And what exactly was your point? Yes, this is the example I was really talking 
about, i.e., Mike's example. Specifically,

DEFINE MACRO AssignPi(precision)
 pi=4*atan(1.0 %% precision %% 0)
END DEFINE

EXPAND AssignPi(0D) ! Fine
EXPAND AssignPi(0 D) ! Not fine 

I find this subtle. Yes, it may be my limited mind, but that doesn't change 
the fact that this is bad design, IMO.

> ? 100 ?EXPAND statement(FORMAT(I10))
OK.
> Or allow it with
> ? DEFINE MACRO statement(X)
> ? ? X = 3 ! This is an assignment statement
> ? END MACRO
Perfectly fine.
> and disallow it with
> ? DEFINE MACRO statement(X)
> ? ? X ! This is a statement
> ? END MACRO
Also perfectly fine. In neither case are there blank separators in the EXPAND 
that subtly affect the meaning. This is perfectly fine according to my "silly 
coding standard":

DEFINE MACRO Declare(default_accessibility)
default_accessibility
REAL :: X
END MACRO

I have no problem with a macro dummy expanding to produce a whole statement, I 
have a problem with allowing *meaningful* blanks in the actual argument 
lists. Blanks that do not change the meaning and merely add clarity are 
great.

You may be right that adding a restriction here would make the implementation 
more difficult. I accept such concerns.

> I expect you to come back at the first public comment period with
> completely developed specs + syntax + edits for including commas
> in macro actual arguments. ?Maybe WG5 will buy it.
Again, I will repeat: I never wanted, do not want, or care about including 
commas in macro actual arguments. I want macros that are not statement-level 
macros, but rather, produce comma-delimited sequences. For example, a macro 
that can produce ":,:,:". This is an entirely different kettle of fish from 
what you think I want.

> In the meantime, arguing that macros should have extra restrictions
> just because we didn't include your favourite subfeature is IMNSHO
> totally out of order.
You brought in my (not so favorite) subfeature. I was arguing for extra 
restrictions because Mike brought an example that pointed out to a situation 
I had not thought of before. It has absolutely nothing to do with commas, it 
is about spaces.

Aleks