Inconsistency with #print arguments

[wallyg]

Using an up-to-date Windows 10 and FBC 1.08.1

I am trying to debug a complex set of macros.

By the way, thank you for __FB_EVAL__ and __FB_UNQUOTE__ ...

1) I insert a #print statement in the innermost macro For instance

#Macro ...
.
.
.
#Print __Line__ And it properly prints 23

However, if I instead insert

#Print text __LINE__ it prints text __LINE__ and not the text 23 I expected

#Print __LINE__ text However does properly prints 23 text

2) Any chance there is a simple way to get the following

#Define beta 19
#Define alpha __FB_EVAL__(beta+2)
To define alpha as 21 and not __FB_EVEL__(beta+2)

The obvious problem is that by the time I use alpha, beta has changed value.

3) As an aside. #Print __FB_EVAL__(beta+2) does work and prints 21

and #Print text __FB_EVAL__(beta+2) prints text __FB_EVAL__(beta+2)

[fxm]

1)
#Print __FB_JOIN__("text ", __LINE__)

3)
#Define beta 19
#Print __FB_JOIN__("text ", __FB_EVAL__(beta+2))

[wallyg]

Thank you for the workaround for this inconsistency. I am just beginning to study these new __xxx commands and had not put any effort into the FB_JOIN one yet.

But the original question was not for a workaround, but an explanation of why the item in question was expanded in one case but not the other. And how to make it expand all items on the line before printing.

Also, the second part is important to me. I wanted to create a macro that would take the number of previous calls to the macro add an integer value and use it as the value on a generated case statement and as the subscript for several arrays. I need a compile-time variable that could be increased by some integer value each time the macro is called.

It is too bad we do not have a command like #define that does all normal substitution on the line and then stores the result in the name specified on the #define command. #EQU would be nice (a command name I used in the 60s and 70s when I did major assembly language development).

Thank you all for your consideration and help.

[coderJeff]

But the original question was not for a workaround, but an explanation of why the item in question was expanded in one case but not the other. And how to make it expand all items on the line before printing.

I can explain what it's doing, but honestly I don't know why it was made that way.
An expanded syntax of #print might be seen as:
'#print [text1 [text2 [ ... textN ] ] ]'

- comments are skipped
- text1 if present is always expanded
- text2 ... textN is never expanded
- white space between text1, text2, etc is condensed to a single space

Also, the second part is important to me. I wanted to create a macro that would take the number of previous calls to the macro add an integer value

It's possible but not too friendly. (I posted this example somewhere, but I can't find where now, so here it is again)

Code: Select all

#macro do_undef( sym )
	__FB_UNQUOTE__( __FB_EVAL__( "#undef " + sym ) )
#endmacro

#macro do_define( sym, expr )
	__FB_UNQUOTE__( __FB_EVAL__( "#define " + sym + " " + __FB_QUOTE__( __FB_EVAL__( expr ) ) ) )
#endmacro

#macro EQU( sym, expr )
	do_undef( sym )
	do_define( sym, expr )
#endmacro

EQU( "a", 1 )
#print a
print a

EQU( "a", a+1 )
#print a
print a

EQU( "a", a+1 )
#print a
print a

EQU( "s", "hello" )
#print s
print s

EQU( "s", s + " world"  )
#print s
print s

[wallyg]

Thank you very much.

I will make great use of these macros. If it works and does what I want it to do, who cares how ugly the innermost details are.