On Tue, 13 May 2008, Szakáts Viktor wrote: Hi Viktor,
> Do you think this logic could be moved to the compiler (rather > than the PP), to avoid these drawbacks? I understand > preprocessed Clipper/Harbour code normally cannot have any > non-ASCII chars, except inside string delimiters (plus maybe > some other special, but well defined places). Our compiler does not accept any national characters so if you have any code with national characters not eliminated (or converted to strings) during preprocessing then compiler reports syntax error. If you have any code with national characters which can be preprocessed and compiled by Harbour then it means that PP rules cleanly eliminated such characters. Moving some PP logic to compiler does not change anything here. We can only add one bison rule for HB_PP_TOKEN_TEXT to generate "illegal character" error message instead of syntax error if it' really necessary. BTW in some situations Clipper's also generate syntax error instead of illegal character, f.e.: x[błąd] := 1 It happens inside [] when PP cannot recognize it immediately as string. In such case 'illegal character' error message is disabled by Clipper but it still streaps all national characters. As result you have: x[b d] := 1 it means that it compiles without any errors code like: x[są] := 1 // => x[s] or: x[żółty] := 1 // => x[ty] What is IMHO wrong. In such case you have situation like the one you wanted to avoid but it happens only in Clipper not in Harbour. In summary current Harbour behavior for me is much more cleaner. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
