Hi Przemek,
----- Original Message -----
From: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
To: "Harbour Project Main Developer List." <[email protected]>
Sent: Friday, May 09, 2008 12:30 PM
Subject: Re: [Harbour] Re: .ppo selectively skips #line ... directives
--- 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_
the #define is on _EXPAND_() not on _EXPAND_, so #undef _EXPAND_
won't be substituted, but at the same time it #undef's _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>
In this example using 1_ instead of %% also works anyhow it can be
written in simpler way. But first please note that in Clipper it's
not possible to use #undef <NAME> inside result pattern because if
<NAME> is defined then it is substituted. I can only guess that the
above is some type of mixed Clipper and old PP code. If you want to
use #undef in such way using Clipper's PP then you have to put it
in a separate file and use #include directive.
Indeed, this is a ca-clipper only set of rules
Now alternative version:
--- system definitions -----
#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 => #undef _EXPAND_
#xCOMM MACRO RESUME => #define _EXPAND_
#xTRAN ppparam( _EXPAND_ <f> | <b> [, <a,...>] ) => <b>
#xTRAN ppparam( <f> | <b> [, <a,...>] ) => <f>( <a>, )
# TRAN function ppparam( [_EXPAND_] <f> | <b> [, <a,...>] ) => ;
func <f> ; PARAM <a>
# TRAN procedure ppparam( [_EXPAND_] <f> | <b> [, <a,...>] ) => ;
func <f> ; PARAM <a>
--- end of system definitions -----
It gives the same results is much faster and IMHO simpler.
Thanks, i assembled the original overnight, might have had no clear mind ;-)
It's for Harbour only. If you want to adopt it to Clipper then you have
to make the trick with #include I've written above: create file undef.ch
with one line:
#undef _EXPAND_
and in the above code change:
#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)
I intentionally haven't used TRANS rules because each time you call
MACRO SUSPEND / MACRO RESUME new rules are added and the PP table is
systematically growing up reducing the memory for compiler and slowing
the preprocessing. Clipper's PP does not have #untrans directive.
But if you change it to use TRANS then it will not be necessary to
make the trick with #include.
In the hurry i must have thought it demonstrates an example of the need for
the 'delayer', but your alternative makes it in this context overdue
yes, ca-clipper can't #untrans and is one of the reasons why (o)ceans'
transpiling needs several ca-clipper passes; apart from prefuncs i use sth
called prevars - this is also sth that uses undocumented features and might
not work in harbour - haven't tested yet
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)
{ ...
In this code you make two different tricks to disable infinite
translation.
1-st you added additional dummy parameter to function call so instead
of fun2( 3, 5 ) we have fun2( 3, 5, ) and this is not recognized
by #define declaration
2-nd for function declaration you moved parameters to PARAM statement.
I could have used an additional foo formal arg on the definition, but
switched to PARAM for you to think hard for a better solution ;-))
Such tricks are possible if you have alternative syntax which is not
affected by your PP rules. Just like the above trick in C which is
also for one situation only and resolves the problem by alternative
code.
If you need general solution then we should introduce new PP token
which is significant for PP but neutral for compiler. F.e. <->
as result marker.
#trans func( <a,...> ) => func( <-> 1, <a> )
The <-> in result pattern will block infinite translation and because
it will be invisible for compiler then it will not break compilation
process. I can add such marker in the future.
And you did! That would be welcome, i vote for!
kind regards,
frank
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.11/1422 - Release Date: 8/05/2008
17:24
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
