LINENO can not be used as part of a variable.

[rikky]

Hello,

I tried for whatever reason to use a variable like SECOND_LINENO
But as soon as you want to print it, it gives a compiler error.


PRINT STR$(SECOND_LINENO)
Description:
file 'blabla.bac' line 1092: PRINT STR$(SECOND_LINENO)
Cause:
'SECOND_1092' undeclared (first use in this function)

When I use LINENO2, Then I do not even have to PRINT IT, to get an error.

Description:
file 'blabla.bac' line 1090: LINENO2 = LINENO
Cause:
expected identifier or '(' before numeric constant


LINENO_TWO gives another error

Description:
file 'blabla.bac' line 1090: LINENO_TWO = LINENO
Cause:
invalid suffix "_TWO" on integer constant

SECOND_LINENO_TWO however cracks when you want to print it, like the first example

SECOND_LINENO_TWO = 3
PRINT STR$(SECOND_LINENO_TWO)Description:
file 'blabla.bac' line 1098: PRINT STR$(SECOND_LINENO_TWO)
Cause:
'SECOND_1098_TWO' undeclared (first use in this function)



Hmm, maybe this is normal behaviour for BaCon that you cannot use variables that include keywords in their names.
But No, All the other keywords that represent a numeric value that I could find so quickly, behave  normally.

I tested : RETVAL COLUMNS FALSE MYPID PI RND TIMER and TRUE
Not thoroughly, but at least with a word before the keyword.

Also other non numeric keywords like VERSION$ seem to work, when you make for example MY_VERSION$, it works.

So it's got something to do with LINENO.

Since you were on the lookout for this tiny glimpses, I thought to report it.

 Rik. 

[Pjot]

Thanks rikky,

You're right, the reason for this is that LINENO needs to be evaluated during compile time at the actual line number, and therefore, it is the only predefined variable which is 'parsed' by the BaCon tokerizer (actually, the letters LINENO are replaced by the line number).

That still means this behavior is wrong, I will fix it shortly.

Thanks again!
Peter

[Pjot]

Hi Rikky,

Sorry for the delay but the CLang problem reported by Joe took a little longer than expected.

The LINENO issue is solved now. In more recent versions, BaCon keeps track of the actual line number using preprocessor macros, and therefore, LINENO can simply be mapped to such macro.

This also reduced the codebase with a few lines

If you checkout the latest beta then you should not run into this problem anymore.

Best regards,
Peter

[rikky]

Thanks.

If I may be so bold,
can I then request for another standard BaCon variable?

LINENO$
Which is basicly just STR$(LINENO)

It types a bit quicker for debugging purposes.

 Rik.