Przemek,
----- Original Message -----
From: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
To: "Harbour Project Main Developer List." <harbour@harbour-project.org>
Sent: Thursday, May 08, 2008 3:07 AM
Subject: Re: [Harbour] Re: .ppo selectively skips #line ... directives
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]
yes, there was a difference between xharbour and ca-clipper; sth that was
discussed in the old forum iirc
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:
It's amazing what insight i gain touched by your expertise; you're right all
the way, i guess at least, for these internal details have always been out
of my reach; my school was trying, trying and coming up with sth that seemed
to do the job - when you'll see the constructs i did come up with, you'll
understand it may not be the perfect strategy i used, but it is yet
surprisingly powerful; single pp rules that span over 30 lines of intensive
prefunc calls (see below) and macro's for the more complex transpilation
requirements are no exception in (o)ceans' actual translation system;
but i keep learning, and from the bests ;-)
#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.
At this point, for the project's needs, please don't mind me taking the time
for exploring; anyhow, i wonder my ongoing exercises with the ca-clipper pp
will still reveal things you don't already know, but i might document some
of the better organised techniques some day; if you think it can be of
interest to the community, i could do this sooner than only when the time
comes the project is going open source. What do you think?
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. ))
this is true, but i wanted sth that would never trigger upon (possible)
manifest constant (user-) defintions and i make use of rules where <x>
figures as in a( [<x>] ) with a repeating characteristic; to force infix pp
evaluation precedence i found this technique to work well, along with
another strategy, which works equally well but is not usable in all
situations; the latter is to have inner prefuncs (such as b() in the
example; i.e. preprocess-time functions, so to say) resolve into a result
which is preceded by a question mark ?, so that b(...) should be evaluated
first anyhow; note that in this case, this technique is not so usable since
it requires
#xTRAN a( ?<x> ) => aDefault( <"x"> )
which is not able to process when for <x> no prefunc is to be evaluated
first (which will provide the upfront ?)
#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. )) // aSpecial( .T. )
a( b( .F. )) // aSpecial( .F. )
if you see the usefulness for a 'forcer' or 'delayer' to change evaluation
precedence, wouldn't it be a good idea to document this technique, and
possibly agree on what combination of operator to 'standardize' for it; of
course it should be an operator combination that is likely never going to be
useful for anything else in the compiler; i'll look into s_operators in
ppcore.c to avoid valid operator combinations, and come up with a
suggestion.
As you can see it works with Clipper's and Harbour's PP.
For whomever wonders what applicability pp evaluation precedence
modification is useful for, here's a quick idea regarding how to define pp
macro's that are suspendable and resumable at specific places in source
code, and that avoid to also substitute a corresponding function definition,
for the case where this macro was suspended, leading to the effect that the
macro behaves just like a normal function call (for which the corresponding
function needs to be defined somewhere)
--- system definitions -----
#xTRAN ppparam( , <f>, <b>, [<a,...>] ) => ;
PPIIF( %% _SUSPEND_(), <f>(<a>,), <b> )
// removing %% in line above leads to wrong results
# TRAN function ppparam( , <f>, <b>, ) => func <f>
# TRAN function ppparam( , <f>, <b>, <a,...> ) => func <f> ; PARAM
<a>
# TRAN procedure ppparam( , <f>, <b>, ) => proc <f>
# TRAN procedure ppparam( , <f>, <b>, <a,...> ) => proc <f> ; PARAM <a>
#xCOMM MACRO SECTION BEGIN => #undef _EXPAND_
#xCOMM MACRO <f>( [ <a,...> ] ) <b> => #define <f>( <a> ) ;
ppparam( _EXPAND_(), <f>, <b>, <a> )
#xCOMM MACRO SECTION END => #define _EXPAND_()
#xCOMM MACRO SUSPEND => #xTRAN _SUSPEND_\\() => .T.
#xCOMM MACRO RESUME => #xTRAN _SUSPEND_\\() => .F.
#xTRAN _SUSPEND_() => .F.
#xTRAN %% =>
#xTRAN PPIIF( <x>, <a>, <b> ) => <b>
#xTRAN PPIIF( .T. , <a>, <b> ) => <a>
----- start of usercode ----------
MACRO SECTION BEGIN
MACRO fun1( a, b ) a + b
MACRO SECTION END
procedure main
MACRO SUSPEND
qout( fun1( 3, 5 ))
MACRO RESUME
qout( fun1( 3, 5 ))
MACRO SUSPEND
qout( fun1( 3, 5 ))
main2()
return
function fun1 ( a, b )
return a + b
MACRO SECTION BEGIN
MACRO fun2( a, b ) a - b
MACRO SECTION END
procedure main2
MACRO SUSPEND
qout( fun2( 3, 5 ))
MACRO RESUME
qout( fun2( 3, 5 ))
MACRO SUSPEND
qout( fun2( 3, 5 ))
return
function fun2 ( a, b )
return a - b
----------
since neither in ca-clipper/harbour it is possible to apply P.J. Plauger's
suggestion to avoid macro defines to trigger upon corresponding function
definitions as he does in his C implementations, the only viable alternative
i've found so far, is sth like above; in C it is enough to do:
#define someMacro( a, b ) a+b
int (someMacro)( int a, int b ) // definition (guarded against substitution)
{ ...
kind regards,
frank
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.10/1421 - Release Date: 7/05/2008
17:23
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
