Hi Przemek,
----- Original Message -----
From: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
To: "Harbour Project Main Developer List." <harbour@harbour-project.org>
Sent: Wednesday, May 07, 2008 4:50 PM
Subject: Re: [Harbour] Re: .ppo selectively skips #line ... directives
On Tue, 06 May 2008, frank van nuffel wrote:
[>> snip]
But it was a bug in old PP. Clipper also generates such error.
It's caused by the fact that PP
o([<_O_>])
has to decode as
o("<_O_>")
i confirm; actual PP behaviour is the same as ca-clipper .oO had forgotten
about clipper's since the old PP was inserted for this pass to process
I cannot change it because it will introduce many other incompatibilities.
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
But you can add workaround yourself, f.e.:
#define _SB [
_PASS3 #xTRANSLATE c9type\( o(_SB<_O_>]) [ ,<_ ,...>] ) => ;
VALTYPE (<_O_> %\% _SB ,<_ >] )
and such code will work also with Clipper's PP.
yes, that'll do just fine
[>> snip]
The
ca-clipper compiler always echoes to the std output, which is
redirectable
to a file - but this is really not important
Not always. In general it's rather reverted. Here I'd rather suggest to
add compiler switch because even with DOS/Windows builds user may work
using BASH/MSYS and will expect compatible behavior with other GNU tools
they are using redirecting the output.
That's fine by me .oO perhaps /q1
PPLIB is a possibility, but in the run i'm hoping to move away from a pp
based transpilation process for my project, only now hoping to switch the
old xharbour pp for this new one of yours, if modifications to the
implementation of the multi-pass approach are minimal.
It was not my intention to replicate old PP behavior. I was interested
only in Clipper compatibility and the results seems to be quite good.
Only few intentional or unexpected but widely used extensions from old
PP were adopted to new code.
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 ^^
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
frank
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.9/1420 - Release Date: 7/05/2008 14:12
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
