> 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.
And yes, the best way to enable it is in configure script.
> > The second one, just a thought: looks like C too much, is there a way
> > to "JALify" it? I'm thinking in something like a procedure/function
> > syntax: "macro ( ) is ... end macro".
>
> This of course would be the best solution, but I suspect it would require
> non-trivial changes to the parser. If jal could parse from a string (starting
> from an arbitrary point in the original file, and resuming to the same itpoint
> afterwards), it would be quite easy to do, but I doubt it has this
> functionality.
> I'll try to think if I can envision a solution, but someone with a deeper
> understanding than mine of the jal parser could give better indications.
>
> Ciao,
> Marco
>
Let's go with my first question, and then if all it's ok will find
a solution here.
Hi, I've added support to jal for cpp-like preprocessors (cpp, gpp, ...). This essentialy allows to write macros using #define (and correctly handle line...
... Hi Javier, I apologize for the late answer, but I've been out of town. ... of course. The main use of preprocessor support in jal is to write macros, short...
... I've added that switch. Now if you run jal with the "-P" switch, it will invoke cpp for you. Compiling the example of the previous message would become: $...
Hi Marco, Sorry, I've been busy. ;) Just 2 questions. The main one: seems that needs an external C preprocessor, isn't it? This will be useless for 95% of...
... 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...
Hi Marco, ... 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 ...
... You are right, it would impede code sharing. I think of this feature as a "sharp knife", to be used exclusively when unavoidable, but I understand that ...
... 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: ...
... I agree, but while on unix-like systems a pre-processor is (almost) always present, on other systems (windows), it is not. I'm not interested in windows ...
Hi all, ... Marco, you hit in the bulls eye. Ask in the jallist how many of them have a C compiler to build latest JAL sources .... ... and now think that...
... Yes, I understand. ... This sounds great! Thanks. In the meantime I'll try to come to a more integrated solution. I'll keep you posted. Cheers, Marco -- ...
Hi all, Available patches in jal.sf.net: ID Summary 1352435 10Fxxx support 1352433 Preprocessor support 1118846 JAL 16F648 Extensions Regards, Javi....