$ifdef highlighting

[Martin_fr]

The "problem" with {$ifdef} is that everything that comes after a legal identifier string consisting of the  ' _', 0..9,'A..Z','a..z' is treated as a comment, so {$ifdef 5+1=true} resolves to 5 because +1=true is a comment.
The string is cut off at the first character or symbol that is not in that set.
In this case +.
OTOH {$if 5+1=6} resolves to true because {$if} allows expressions.
And there is where the whole discussion went wrong.
All this is documented. The compiler handles the options correctly but codetools doesn't.

Codetools should parse  ' _', 0..9,'A..Z','a..z' correctly, which is basically the set for any valid pascal identifier char except the escape char &

Neither is the "+" syntax mentioned? So while your statement is correct by itself, it has nothing to do with this thread. Not sure what the purpose of it is meant to be....

[Thaddy]

The + syntax is part of the accepted expression syntax for {$IF}
{$ifdef does not know expressions...

In {$ifdef} it is the start of the comment in your example.
Valid identifier characters are documented and is simply the set for any pascal identifier character,  _,0..9.A..Z,a..z (with & excluded since it is an escape)

Is this so hard to follow?

[Thaddy]

It has everything to do with the syntax highlighting which is not correct because it is not parsed correct: all I tried to explain the hwhole time.
The compiler and fcl-passrc parse it correctly but are not highlighters.
The colorizer should not {$ifdef and {$if the same, which it does now.

[440bx]

I find it disconcerting that the preprocessor accepts {$define 0}

I expected that whatever follows the $define would be required to follow Pascal's valid identifier rules.

That's not the only unexpected value it allows.  It allows just about any character, e.g, +

For instance, the preprocessor "sort of" accepts

Code: Pascal  [Select][+][-]

1. {$define +}
2. {$ifdef +}
3.   {$FATAL + is defined}
4. {$endif}
5.  

The define is accepted, OTH, the ifdef is rejected (unlike with a numeral.)

The "variability" in what the preprocessor considers a valid identifier can make for some ambiguous and confusing situations.

All that said, this thread's topic wasn't what the preprocessor considers a valid/possible name but, maybe that should be given some thought because it is currently a rather nebulous area, i.e, nowhere in the documentation does it say what is and isn't a valid preprocessor name/identifier.


Conclusion 1, a $define should probably apply the same rules the $ifdef applies (it currently doesn't.)
Conclusion 2, a valid preprocessor name/identifier should probably be limited to valid Pascal identifiers.

[Thaddy]

I expected that whatever follows the $define would be required to follow Pascal's valid identifier rules.

But it does: anything in _,0..9,A..Z,a..z is a composing character of a valid Pascal identifier: what makes you think otherwise?
Also: all macro elements are strictly not Pascal, but bolt-on's working with a separate parser/tokenizer (in this case two separate ones)
The highlighter should do the same...
You can unite {$ifdef} and {$ifopt}, but {$if} needs a different parser/tokenizer in the highlighter. One is a simple state machine, the other one is an expression parser.

[440bx]

But it does: anything in _,0..9,A..Z,a..z is a composing character of a valid Pascal identifier

Apparently you need to be informed of the obvious: the numeral zero is not a valid Pascal identifier.  Maybe you need to read the manual again to refresh your memory about what is an isn't a valid Pascal identifier.

[Thaddy]

It is for the purpose of the macro language for {$Ifdef} completely valid.
I simply do not understand your point at all:
If you want the highlighting fixed, the highlighter *must* be able to parse both flavors.
What you simply fail to admit is that the zero in {$define 0} can never leak to Pascal code: it is a macro definition. It is not part of the Pascal language.
You are all being stubborn. Fix the highlighter by having two separate parser/tokenizers for the two types of defines.

[440bx]

It is for the purpose of the macro language for {$Ifdef} completely valid.

Nice try but, no cigar.

I simply do not understand your point at all:

Of course you don't.   Very convenient for you.

Since you're on a roll... explain why {$define +} is acceptable given that {$ifdef +} is not.   It's going to be quite amusing to see what non-sense you come up with to justify that and, if you say "macros" again then provide an example that supports your point.  There is your homework... get to work!.