Proposed new preprocessor usage scheme for 4.0
- Posted by jimcbrown (admin) Jan 30, 2011
- 1372 views
I think I do remember a brief discussion about that. A problem with the pre-processor is that it is not designed to handle multiple pre-processing tasks. For example, the Euphoria programs that create these web pages were run through a specific pre-processor that knows about web-stuff (webclay). Now if someone uses a swap operator in the webclay code, the output of the webclay preprocessor would then have to go through the 'swap' pre-processor as well, and I'm not sure if that is even feasible or desirable.
A pre-processor is designed to implement one specific transformation. If your code has multiple 'pre-processor' elements, it needs to be run through multiple pre-processors so that all the transformations are done. The management and performance of such a set of operations may not be so desirable.
One particular concept, which although it has never been made official is currently supported by the current 4.0 preprocessor handler, is that each preprocessor is given a unique file extension and that the different preprocessors input and output are kept separate from each other.
For example, take the following: a preprocessor that handles only .h files (generating Euphoria dll/so library wrappers) combined with the webclay preprocessor that handles only .etml files and also a preprocessor that wraps .sql files (raw SQL statements) in (for example) edbi code, combined in the main .e/.ex code - that is unhandled by any preprocessor. The main .e/.ex code can directly include .h files and access the library, include the .sql files and easily do sql work, and include .etml and do dynamic html page generation. We have now combined 4 languages - C's header files and SQL and HTML and Euphoria.
None of that code is meant to go though multiple preprocessors but by using multiple preprocessors separately, we've saved the trouble of either having to convert or wrap C/SQL/HTML code and text by hand, or the trouble of having to deal with manually running the preprocessor and maintaining the output Euphoria code for a long term program.
So, this particular concept, that of preprocessor separation, where instead of running the same code through multiple preprocessors sequentially to add multiple features, we instead run separate parts of the code of the application through different preprocessors to make use of different features in different parts of the code, allows one to take advantage of multiple preprocessors in a far more practical, and maintainable, way.
Of course, this is not so useful if your goal is to be able to add features X, Y and Z from preprocessors A, B, and C and then use those features anywhere and everywhere in your code. (If you want to do this, I recommend dot4.)
