Although a very big work
Yes, it is a lot of work. IF (note the big IF) I decided to go ahead with it, I would definitely like and appreciate some help.
I would like to see such a tutorial.
Pleased to read that. (normally, I'd say: pleased to hear it but, I read it not heard it
)
First, you should indicate one or two modern affordable books as reference about the needed deep theory.
Those outrageously priced old books are always cited here because they showed the whole process from toy language source code (text) through useless working binary.
Strangely, it doesn't really take much "deep theory". A recursive descent parser is easy to understand and implement. As far as book recommendations, the one book I really like, which I have recommended a number of times already is definitely _not_ affordable.
Then, if possible, your tutorial should show the whole process: Preprocessor, Compiler, Assembler, Linker, Loader, and Memory.
I don't have a design at this time. At this time, I just want to find out if there is a reasonably significant amount of interest in such a tutorial. That said, I don't see a preprocessor being there. The reason being that, in my experience, preprocessors tend to make a program more difficult to understand because what the programmer reads isn't what the compiler sees. IMO, while a preprocessor is desirable in some ways, it creates too many undesirable problems resulting in potentially very hard to understand and maintain code.
Again, if possible, your tutorial should include at least the types: Integer, Float, String and Date. And Procedures and Functions.
Integer, float, records, pointers, procedures, functions, strong typing and inline scopes: definitely. Exception handling: almost certainly (though maybe not in the first implementation.) String and Date: I see them more as features that belong in a library, not in the compiler. Just the "definitely(s)" add up to a fair amount of work.
Beyond being imperative procedural, it would be amazing if a minimum usable imperative object-oriented paradigm (OOP) could be added.
I would definitely not include any OOP because that can really complicate matters.
The topics for the compiler part could be: Lexical Analyses, Syntax Analyses, Semantic Analyses, Intermediate Code Generation, Error Handling, Exception Handling, Code Optimization, and Target Code Generation.
While I don't have a design at this time, I lean towards error handling implemented the "Turbo Pascal" way, every error stops the compilation. That implies, the compiler has to be _blazingly_ fast, which is doable.
Code optimization and generation: that's where the real "fun" starts. I would focus on "hand written assembly like" size code that is reasonably fast. I really like small executables, that is a _must_.
Thank you for your input. I appreciate it.
ETA:Use or build?
Use not build. Compiler-Compilers can be used to ensure the grammar doesn't contain ambiguities and/or conflicts. To me, that's their primary appeal but, when it comes to build it, hand coded scanners and parsers are it.
ETA[2]I would be interested in seeing such a tutorial, and potentially using it, time permitting...
Noted. Thank you for the feedback.