On Wed, 07 May 2008, frank van nuffel wrote:
Hi Frank,
> indeed, and shouldn't, by all means - in the PP passes, which are ca-clipper
> passes, this is sth i took care of, similarly to what you suggest below;
> sorry i overlooked that this _PASS3 technique was used in an xharbour-only
> PP pass, where the rules were intended to trigger (the previous ca-clipper
> pass skips these with #COMMAND _PASS3 <*_*> => // empty) .oO or even with
> no such #COMMAND to let these lines just generate errors, that don't matter
> during that pass
In current PP <*id*> should work like in Clipper allocating data
to the end of processed line. AFAIR in the old PP ; was additional
stop condition. In some cases it may be useful to have some stop
tokens for wild markers. I left note about it in ppcore.c[3596]
> >Just make some tests and if you will find other problems then please
> >inform me. F.e. I can see that separating operators in output can be
> >a problem for you (%% in this example). If yes then I can tell you
> >how to disable it. It was an extension to fix some problems with old
> >[x]Harbour lexers (FLEX/SIMPLEX) which is not longer necessary because
> >now Harbour compiler adopts PP tokens as is without additional string
> >decoding.
> afaik, in ca-clipper PP there are three 2-char tokens that behave special:
> :: and %% and ^^
No, they are pair of tokens. Clipper divides parsed text on tokens
at the beginning. It recognizes numbers, strings, logicals, macrotexts
macrovars, identifiers and predefined operators. The list of operators
which Clipper's PP knows you can see in s_operators in ppcore.c.
Here you can see all multi character operators which Clipper recognize
as single token. All of the above (:: %% ^^) are pair of tokens and it
doesn't matter it is or not space between them, f.e. just try:
#trans a( ^ ^ ) => qout( "translated" )
a( ^^ )
And now they are interacting with your example. Two different rules
are used: first for :: and second for %% and ^^.
The first rule says that expression cannot start with ':' token, f.e.:
#trans a( <x> ) => qout( "translated", #<x> )
a( : )
a( :: )
a( :x )
a( ::x )
a( : : x )
none of the above can be translated by Clipper. Unfortunately we
inherited from xHarbour WITH OBJECT syntax where :<msg> is used.
It causes that I couldn't replicate exact Clipper behavior because
such simple code will not work:
WITH OBJECT errorNew()
? :canRetry
END
But this introduce some incompatibilities. F.e. in example above
and in your code. But also in some commonly used code, f.e.:
@ 0, 0 SAY xVar PICTURE get:pict
This code was wrongly preprocessed. So I had to add hack and
now PP checks number of spaces before : and when is zero then
it works like Clipper. This hack was removed from xHarbour
so current xHarbour PP cannot preprocess above line. It
works like Harbour for:
@ 0, 0 SAY xVar PICTURE get :pict
I'm really sorry but as long as we will keep current WITH OBJECT
syntax I cannot resolve the problem. Just simply it was wrongly
chosen without enough knowledge about PP rules.
The second rules is used for %% and ^^ says that expression cannot
contain some combinations of operators. There are much more similar
combinations, f.e. %*, +*, /+, etc. f.e.:
#trans a( <x> ) => qout( "translated", #<x> )
// not translated
a( %% )
a( *+ )
a( +* )
a( + + )
a( - - )
a( a %% b )
a( a % % b )
a( a %* b )
a( a % * b )
a( a *+ b )
a( a +* b )
a( a /+ b )
a( a / / b )
a( a / * b )
a( a * * b )
a( a + + b )
// these are translated
a( a $$ b )
a( ++ )
a( -- )
a( a - - b )
At the beginning I wanted to replicate exact Clipper behavior but
when I made deeper test I've found that it causes that Clipper's
PP cannot preprocessed correctly some valid expressions. F.e.
QOut( 2 + + 2 )
is prefectly valid code but
? 2 + + 2
does not work due the above rule. But it works for:
? 2 - - 2
I can only guess that someone who created base Clipper PP condition
hardcoded that some math operators cannot be in single expression
and then added some exceptions for commonly used code (f.e. multiple
negations) which was wrongly preprocessed. I decided to not replicate
it because PP does not know all compiler rules and cannot make it will.
Anyhow it's possible to make it exactly like in Clipper and it's even
quite easy modification.
> while none of them are valid operators for the ca-clipper language, they can
> be used to force delay in pp
>
> #xTRAN %% => // has delaying effect
> #xTRAN :: => // has delaying effect
> #xTRAN ^^ => // has delaying effect
>
> #xTRAN !! => // has no delaying effect
> // or any other operator
>
> #xTRAN a( <x> ) => aDefault( <"x"> )
> #xTRAN a( .T. ) => aSpecial( .T. )
> #xTRAN a( .F. ) => aSpecial( .F. )
>
> #xTRAN bDefault( .T. ) => .T.
> #xTRAN bDefault( .F. ) => .F.
>
> #xTRAN b( <x> ) => bDefault( <x> )
>
> a( b( .T. )) // aDefault( "b( .T. )" )
> a( b( .F. )) // aDefault( "b( .F. )" )
>
> a( %% b( .T. )) // aSpecial( .T. )
> a( %% b( .F. )) // aSpecial( .F. )
>
> a( :: b( .T. )) // aSpecial( .T. )
> a( :: b( .F. )) // aSpecial( .F. )
>
> a( ^^ b( .T. )) // aSpecial( .T. )
> a( ^^ b( .F. )) // aSpecial( .F. )
>
> a( !! b( .T. )) // aDefault( "!! b( .T. )" )
> a( !! b( .F. )) // aDefault( "!! b( .F. )" )
>
> these 'forcers' (as i call them) enable pp to work from inside outward,
> first processing b( .T. ) or b( .F. ) and only then a( ... ) on that result
> there are more thingies i used, but i'll have to lookup those
You do not have to use :: %% or ^^ in the above example. You can use
anything what will cause that in:
a( <x> )
<x> will not be single expression for CA-Clipper. F.e. add to above
code:
#xTRAN __ =>
#xTRAN 1_ => // these are two separated tokesns 1 and _ for PP
and then test:
a( __ b( .T. ))
a( 1_ b( .F. ))
As you can see it works with Clipper's and Harbour's PP.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
