After thinking a bit about my 'import' keyword, and after your good
explanation of the problem, I should say that I finally tend to agree with
> I think you're confusing the meaning #include has in PilRC as
> implemented today with the meaning it would have in a sensible
> specification of the .rcp language.
Yes, I think you're right. After all, including a file (no matter its actual
content) should use only one keyword.
> > '#include' is used to include a constant definitions file (C file, or
> > file)
> That is how it is used today, with current PilRC's limited implementation.
> However, in my opinion, if you're going to add things like #define,
> #ifdef, and #include to the .rcp language, i.e., you're going to add
> things that look like the C preprocessor, then the sensible thing to do
> is to *use* the C preprocessor.
That could be the 'right way' to do it, but this is another kind of horse to
do it actually.
I know (from an old project I worked for) that invoking a C preprocessor to
'pre-parse' a file can be tricky if we want to be compiler independant
(particularly on Windows, where the preprocessor is not at a fixed location,
not even in the user PATH sometimes).
That will probably cause more problems than benefits...
> Instead, PilRC grew its own buggy limited implementation of something
> that looked sort of like a C preprocessor. I think this was a serious
> mistake. But at the moment, that is a mistake that is limited to the
> current incarnation of PilRC. Adding an "import" keyword to the .rcp
> language would compound the mistake, widening its scope to any tool that
> parses the .rcp language. Hence I oppose the addition of such a keyword.
Well. That sounds reasonable.
> > If you want to overide '#include' to be able to include RCP file as
> > that would require to hack the ParseDirectives() function, in order to
> > the kind of file we are including (there is already a switch between C
> > and java file based on the file extension).
> That sounds like an entirely reasonable implementation within the terms
> of the current PilRC implementation, which is just one big hack job :-).
I totally agree concerning the remark about current implementation. :-)
As invoking the CPP preprocessor can be difficult, and also do not make the
job entirely, as it does not solve the Java constants for example, I think
that I will rework my patch to override the '#include' keyword to allow
inclusion of .rcp files.
(that will require however the included RCP file to have a .rcp extension,
to handle it correctly. That should not be a problem in practice I think).
> The fact that a lot of crap has already been allowed in is not a good
> reason for adding more crap. :-)
I understand your point of view.
Thanks for your sensible answer.
- Laurent LATIL -