On Tue, 06 May 2008, frank van nuffel wrote:
Hi Frank,
> Yes! great, this works fine - thx
Fine, I'll commit it.
> Gradually i'll explore the new pp to see whether it can replace the need for
> supplementary ca-clipper pp passes, which kind of use quite a number of
> hacks, which i don't expect to being replicable with harbour's pp (and
> perhaps don't need to)
> If you don't mind me mentioning, one such things is
> --- test.prg ---------------------------------------
> #xTRAN %% =>
> #ifndef _PASS3
> #xTRANSLATE c9type\( o([<_O_>]) [ ,<_ ,...>] ) => VALTYPE
> (<_O_> %\% [ ,<_ >] )
> #else _PASS3
> _PASS3 #xTRANSLATE c9type\( o([<_O_>]) [ ,<_ ,...>] ) => VALTYPE (<_O_> %\%
> [ ,<_ >] )
> #endif _PASS3
> proc main ()
> c9type(o(object))
> ----------------------------------------------------
> in my actual header generated code, there's no #ifndef ... #else ... #endif
> around the shown #xTRANSLATE, so as to only show
>
> _PASS3 #xTRANSLATE c9type\( o([<_O_>]) [ ,<_ ,...>] ) => VALTYPE (<_O_> %\%
> [ ,<_ >] )
>
> which triggering is merely controlled by whether the manifest constant
> _PASS3 is defined (with empty value) or not; this enables pass-relevant pp
> rules; only, when preprocessing this snippet with -D_PASS3 the compiler
> complains about Error E0008 Unknown result marker in #translate/#command,
> whereas when _PASS3 is not defined, the very same #xTRANSLATE rule runs fine
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 cannot change it because it will introduce many other incompatibilities.
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.
> Also, it seems that harbour.exe writes to the error device, mentioning the
> number of errors and 'No code generated' - could writing to the error device
> also be controlled by HB_PP_STRICT_LINEINFO_TOKEN or something similar? 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.
> 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.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
