Hi Przemek,
----- Original Message -----
From: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
To: "Harbour Project Main Developer List." <[email protected]>
Sent: Tuesday, May 13, 2008 10:08 AM
Subject: Re: [Harbour] Re: .ppo selectively skips #line ... directives
> #undef _EXPAND_
>to:
> #include "undef.ch"
>Such tricks makes also class(y).ch
i'm aware of such construct, but it isn't necessary here (see above)
Not exactly. There are situations when using indirect #include resolves
some problems which cannot be easu addressed using Clipper's PP.
moreover, ca-clipper only allows one insertion of a directive per command
and it must be the last statement in a multi-statement line; after release
1.0 i'd like to dig into this regarding what similar limits harbour has, if
there are any.
I updated your example to work with Clipper and Harbour and to not use
overloaded #[x]trans rules.
/* --- system definitions ----- */
#xCOMM MACRO SECTION BEGIN => #undef _EXPAND_
#xCOMM MACRO <f>( [ <a,...> ] ) <b> => #define <f>( <a> ) ;
ANY_DEF( ppparam, ( _SUSPAND_() <f> | <b>, <a> )
_EXPAND_() )
#xCOMM MACRO SECTION END => #define _EXPAND_()
#xCOMM MACRO SUSPEND => #undef _SUSPAND_
#xCOMM MACRO RESUME => #define _SUSPAND_()
#define _REPEAT_()
#define ANY_DEF( x, y ) ANY_TRANS( x, y )
#xTRAN ANY_TRANS( <x>, ( [<s:_SUSPAND_()>] <y,...> ) ) => ;
<x>( _REPEAT_() <s> <y> )
#xTRAN ppparam( <f> | <b> [, <a,...>] ) => <b>
#xTRAN ppparam( _SUSPAND_() <f> | <b> [, <a,...>] ) => <f>(
<a>, )
# TRAN function ppparam( [_SUSPAND_()] <f> | <b> [, <a,...>] ) => ;
func <f> ; PARAM <a>
# TRAN procedure ppparam( [_SUSPAND_()] <f> | <b> [, <a,...>] ) => ;
func <f> ; PARAM <a>
/* --- end of system definitions ----- */
i confirm; both ca-clipper and harbour run fine with this version
Please look that if you want to use _SUSPAND_() define then it's
necessary to force switching translation to defines. ANY_DEF() does it.
Unlike the previous one current Harbour's PP uses the same algorithm
for rule parsing as Clipper so it's necessary also in Harbour.
In this test instead of '%%' you were usinf I used _REPEAT_() define.
It makes exactly the same job in changing substitution precedence as
%% in your examples though it also forces parsing DEFINEs. If you do
not want to parse define (in this example is not necessary) then you
can change #define _REPEAT_() to #xtrans _REPEAT_() =>
it is indeed an interesting sample to check, seems like you are suggesting a
good alternative, called _REPEAT_() and indeed the fact it is a #define
makes it even stronger than my #xtranslate based %% forcer - this is
definitely sth to keep in mind, thanks
I hope it may help you to understand the exact substitution precedence
used by PP which is different then described in Clipper documentation.
In fact it looks like:
1. substitute _ALL_ DEFINEs
2. if anything was substituted in last pass goto 1
3. substitute _ALL_ #[x]TRANs
4. if anything was substituted in last pass goto 3
5. if anyhthing was substituted in any of #[x]TRANs passes goto 1
6. substitute _ALL_ #[x]COMMANDs
7. if anything was substituted in last pass goto 6
8. if anyhthing was substituted in any of #[x]COMMANDs passes goto 1
is inference 7 to be true at that point ? afaik, it is omitted, to directly
infer step 8 - the next example is sth i tested years ago, for ca-clipper,
but it works correctly with current harbour also: (making use of your
_REPEAT_() forcer instead of %%)
// ----- same results with ca-clipper and harbour -------------------
#define _REPEAT_()
#xCOMMAND TST <x> => tested( " VIA COMMAND /COMMAND ", <x> )
#xTRANSLATE TST <x> => tested( " VIA COMMAND/TRANSLATE", <x> )
// ------------------------------------------------------------------
#xCOMMAND TESTING => TST "Tst"
TESTING // tested( " VIA COMMAND/COMMAND ", "Tst" )
// NOW AGAIN BUT WITH USE OF THE _REPEAT_() (OPERATOR?)
#xCOMMAND TESTING => _REPEAT_() TST "Tst"
TESTING // tested( " VIA COMMAND/TRANSLATE", "Tst" )
// ------------------------------------------------------------------
the last TESTING command goes thru a #COMM to result in sth that doesn't
readily trigger the other #COMM, due to the upfront _REPEAT_()
but agreed, the next result deviates from this, which i understand as a
chain of #COMM translations since here, due to its placement, _REPEAT_() is
too late; i confirm this is both true in ca-clipper and harbour
// ----- same results with ca-clipper and harbour -------------------
#define _REPEAT_()
#xCOMMAND TST [<x>] => tested( " VIA COMMAND/COMMAND ", [<x>] )
#xTRANSLATE TST [<x>] => tested( " VIA COMMAND/TRANSLATE", [<x>] )
// ------------------------------------------------------------------
#xCOMMAND TESTING => TST "Tst"
TESTING // tested( " VIA COMMAND/COMMAND ", "Tst" )
#xCOMMAND TESTING => TST _REPEAT_() "Tst"
TESTING // tested( " VIA COMMAND/COMMAND", "Tst" )
// ------------------------------------------------------------------
Probably we should discuss it. I think it will be good to also have
named invisible markers which can be used in other rules. I hope that
after 1.0 we can return to this discussion.
Generally, i think i understand everything you explained (the new samples to
confirm identical behaviour in ca-clipper/harbour), so feel free to choose
the time to expand on these invisible markers
best regards,
frank
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1434 - Release Date: 15/05/2008
7:24
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
