I had about the same thought 20 some years ago. I also wanted a more advanced preprocessor which had more scripting capabilities, with knowledge of the C lexical output. For example write a preprocessor script that would call a macro every time a function call was entered.
I also always wondered why there was not a python C interpreter. That is, I thought about writing a C function and having a python script which tested the C code, where C code was run through an interpreter in python. There was no reason to compile the C code if python could just interpret the C code for testing. I really liked this idea as it would mean you could use C as scripting language as you suggested. It would have to have some json configuration to provide information on the endian, size of integer, and basically all the machine specific information you need for C. Which is where the problem comes in. This machine specific details is the hard part. For example is an integer 16bit, 32bit or 64bit. If it is machine specific then your script is not portable. If you have a machine configuration, then that needs to be included with script, which is a pain. At the end of the day it ends up that python is close enough to C that it is easier to use python for scripting. However I still want the C/C++ interpreter in python for testing C/C++ code. Having done opensource projects before I learned that the idea creates no value, it is the guy who implements it that creates value. Also I learned that most people use open source, but a very very small percentage actually contribute to it. So basically if it is a great idea, go make it happen! Note I have not done the python interpreter for C/C++.... On Sat, Dec 28, 2024 at 10:01 AM Paul Markfort via Gcc <gcc@gcc.gnu.org> wrote: > To be clear. > > I am not suggesting that Compilers like GCC be modified to act on the > "#!", or even fully support it. > Just that they be simply modified to ignore "#!" - on the first line > (which should terminate with either a "/r" or "/n"). > This allows the easy creation of scripts to handle an executable Source > file. > Maybe ignore all lines beginning with "#!" - as this would make it easy to > add a line with extra arguments for a script or program that runs the > source file. The compiler itself doesn't need to have any special features > to do that. > I realize that C is not a line oriented language and usually completely > ignores line termination characters (so yes this is probably not a simple > thing to do). > > The point is to make it easier to use C and C++ (and Fortran, etc) to > write small little utility programs. > This will also make it much easier to teach these languages - and for > students (or anyone) to practice ideas. > > Compilation of small source files is so fast these days, that an > interpreter probably is a sub-optimal solution. > Compile, then run helps find errors before the program does anything (One > example of this is perl - which compiles the perl code, then runs it). We > don't need to get into the details of how this would be used - or what the > program that gets started by running the source needs to be able to do. > > > > On 2024-12-28 5:48 AM, Basile Starynkevitch wrote: > > Hello all, > > > > Paul Markfort suggested > >> ...... > -- > -------------------------------------------------------- > The views and opinions expressed above are strictly > those of the author(s). The content of this message has > not been reviewed nor approved by any entity whatsoever. > -------------------------------------------------------- > Paul FM Info: http://paulfm.com/~paulfm/ > -------------------------------------------------------- >
