Javier Martinez wrote:

>Hi Marco,
>
>
>
>>Yes, but if someone doesn't need it, he can just ignore it.
>>
>>One possible solution could be to selective enable the preprocessor support
>>when running the "configure" script, if called with an "--enable-cpp" switch.
>>What do you think about this?
>>
>>
>
> Yes, but what about sharing code? These macro functions will make JAL
>"other" language (JAL-cpp vs JAL), that is you'll not able to share code
>with other "not-cpp" jallians. Should be nice to find a solution
>affordable for all, rather than for a few ones.
>
>
>
>
hello Marco, Javi,

As a non-C-programmer, I cann't understand the full extend /
consequences of this C-isch macro implementation,
but here a few remarks:

1. Macro's can never extend or change the real functionality /
performance of the compiler. This would imply that a macro-machine
should always or best be implemented as a pre-processor.

2. As I showed in JALcc, it's very well possible to create a
pre-processor which is capable of perfoming complex macro actions, while
still holding 100% compatibility with "standard JAL", see
http://oase.uci.kun.nl/~mientki/pic/jalcc/help/jalcc_macro.html
<http://oase.uci.kun.nl/%7Emientki/pic/jalcc/help/jalcc_macro.html>
If you look at the block "Inline Macro,IO-pin, about the end of the
first page, you can see how this is implemented.

3. The mentioned page describes only the build in macros in JALcc, I've
build in user definenable macros, but as I'm not satisfied about them,
they are not made public.

4. I'ld love to come together to get a standard definition of macros
(maybe even fully compatible with mchip-macros), which then can be
implemented in different pre-processors.

just my 2-euro-cents

cheers,
Stef