Gale Paeper wrote:
Oh dear, I'm quite shocked. Why do people make up such strange things? They could easily have made two separate routines (say `ScanEQ' and `ScanNE' -- this might be what can be implemented reasonably in GPC, with different syntax (*)) -- it would have taken them just one more predefined identifier instead of a completely irregular new syntax rule ...
I'm not sure where in the chain from Apple's UCSD Pascal to MPW Pascal the change was made, but in MPW Pascal `ScanEQ' and `ScanNE' is provided instead of Scan.
Even the same names that I'd just made up? :-)
(*) Just a thought. Perhaps the syntax could be handled with more-advanced preprocessor features, in particular string handling. Something like:
{$define Scan(A, B, C) {$if MacroIsPrefix (<>, MacroTrim (B))} ScanNE (A, MacroRemovePrefix (<>, MacroTrim (B)), C) {$else} ScanEQ (A, MacroRemovePrefix (=, MacroTrim (B)), C) {$endif} }How about:
{$define Scan(A, B, C) repeat
Scan in UCSD Pascal is a function, so a compatibility macro must be usable as a function.
var ScanExpression : string(4) value (#B); if (Length(ScanExpression) = 4) and_then (index(ScanExpression,'<>') = 1) then ScanNE((A),ScanExpression[4],(C))
BTW, would these parentheses actually be necessary in Pascal? Sure, it won't hurt to add them, but without the infamous comma operator of C, I think there could be no confusion here, anyway.
else if (Length(ScanExpression) = 3) and_then (index(ScanExpression,'=') = 1) then ScanEQ((A),ScanExpression[3],(C)) else ParameterError; until true;
`repeat ... until True'? (Without trailing `;', BTW.) Perhaps you've read/written too many C macros of the kind `do ... while (0)'.
In Pascal, however, `begin ... end' would seem simpler (in a statement context), wouldn't it? (One of my favourite arguments why semicolon as a separator is better, BTW. :-)
Note: The above assumes the preprocessor treats #B like the C preprocessor does (i.e., string quotes the macro parameter) and that PEXPR parameter is required to be in the exact form that Adriaan cited - without quotes for CH. If the CH part is a quoted char constant, some adjustments are needed to take into accout the embedded quote characters.
He wrote "where CH stands for any expression that yields a result of type char". This would seem to include a character literal, so this problem does occur.
Also, your suggestion would shift quite some work to runtime (string comparisons), and a parameter error wouldn't be detected until runtime. (I didn't check for it in my version, but it could be added and checked for at compile-time.)
If the CH part can be any expression of char type, forget it - I don't think a macro hack is possible for that.
Not without preprocessor string-handling capabilities I think (which we might want to add in the future) ...
Frank