Programming

does this compiler exist

TLDR; 65% of what you want exists as the Rust compiler, which is probably as close as you're going to get at the moment (edit: I was wrong see the comment about racket for a less practical but more flexible system). Take a look at macros like view! on this page. Rust doesnt support html-like syntax, but it does within that view! because someone made a macro that supports it. Rustc doesn't directly have a config file AFAIK but it also doesn't need any build tools (no make, cmake, autoconf, etc) because everything can be done with rust itself (because it's macro system is Turing complete with full file access).

Full Response:

I agree with the general idea, but I think there are lots of misconceptions. Gcc does allow doing things before the preprocess step, after the preprocess step, before the linking step, etc. It's possible, but not easy, to run your own programs inbetween those kinds of steps. As for why there's no config file, it's probably cause gcc is really old, but I'll have to let someone else comment on that.

However, syntax support is effectively a completely different feature request. For example the "adding brackets to indentation" couldn't really/correctly come before the preprocessing step. I mean a really hacky solution like my indent experiment from a long time ago can, but it will never be even slightly reliable because of the preprocessor, multi-line strings, comments and other edgecases. Let me explain.

• The syntax cannot be parsed without running the preprocessor. Things like un-matched brackets are completely allowed before the preprocessing step. It would be literally impossible for the parser to run before preprocessing.
• So let's talk preprocessing. The preprocessor is so stupid it won't even notice the difference between C, Haskell, or Ada. It's just looking for strings, comments, ints, and preprocessor directives. That's it. It has no idea about scopes or brackets or anything like that.
• So for the "adding brackets to indentation" to work, it would need to run its own preprocessor step, then do some parsing of its own, and then run the indent-to-bracket conversion.

But note, preprocessor strings just coincidentally parse the same as C strings. There's already a limitation of the preprocessor failing on, lets say, python where python has triple-quote strings.

That said, preprocessing is actually highly unusual in the sense that it can be done as a separate step. Usually parsing needs to be done as a unified operation. Not to say it can't be modular, but rather the module must be given to a central controller that knows about everything rather than just having a code-transformaiton step.

With those misconceptions out of the way, now I want to talk about the parts I agree with.

IMO the perfect language is the one that has an "engine" that is completely separate from the syntax. And then the language/compiler should allow for different syntax. LLVM IR could be argued as being "an engine", but man is it a messy edgecase-y engine with no unified front-end.

The closest current thing to what you're talking about is almost certainly Rust macros. Unlike the preprocessor, Rust macros fully understand rust and are a part of the parsing process. They are decently close to what you're saying, instead of compiler flags it's just imports within Rust. You can write HMTL, SQL, and other code just right in the middle of a rust program (and it's not a string either, it's actual syntax support). Not only is it possible, but I have been eagerly awaiting for someone to create a garbage-collected syntax within a Rust macro. People have already created garbage collectors, it's just a matter of making a nice wrapper and inter-op.

That said, and even though Rust macros are head-and-sholders above basically every other language, I personally still think rust macros don't go far enough. Indent-based code isn't really possible within rust macros, rust macros can't have imbalanced braces, and there can be escaping issues that prevent things like YAML syntax from ever being possible. They also can't allow for extensions like units, e.g. 10gallons without wrapping it with some kind of delimiter (which defeats the point)

AFAIK currently there is no compiler that supports a composable syntax like that. I've worked on designing such a system, and while I don't think it's impossible, it is extremely hard. There's a lot of complications, like parsing precedence, lookaheads, operator precedence. Two syntax modules that don't know about each other can easily break each other. Like I said, I don't think it's impossible, but it is difficult.

Some of the things you mentioned seem to belong more properly in the development environment (e.g. code editor), and there are plenty of those that offer all kinds of customization and extensibilty. Some other things are kind of core to the language, and you'd really be better off switching languages than trying to shoehorn something in where it doesn't fit.

As for the rest, GCC (and most C/C++ compilers) generates intermediate files at each of the steps that you mentioned. You can also have it perform those steps atomically. So, if you wanted to perform some extra processing at any point, you could create your own program to do so by working with those intermediate files, and automate the whole thing with a makefile.

You could be on to something here, but few people seem to take advantage of the possibilities that already exist, and combining that with the fact that most newer languages/compilers deliberately remove these intermediate steps, this suggests to me that whatever problems this situation causes may have other, existing solutions.

I don't know much about them myself, but have you read about the LLVM toolchain or compiler-compilers like yacc? If you haven't, it might answer some questions.

Have you looked at the Lisps / Scheme / Racket yet? Racket in particular makes it quite nice to go #lang blah at the top of the file and change the parsing or interpretation entirely.

For example all the documentation pages and guides are written in scribble:

https://docs.racket-lang.org/scribble/getting-started.html#%28part._first-example%29

#lang scribble/base
 
@title{On the Cookie-Eating Habits of Mice}
 
If you give a mouse a cookie, he's going to ask for a
glass of milk.

And it has an entire document markup language created in it, which can output pdf or html. But you can still use @ syntax to drop in racket code to compute values. Or create templates.

I even implemented a #lang which took assembly directly (and interpreted it, it was for a class).

So if you are really after full control, you should study Lisps and their macro systems.

Did you read the gcc documentation? Don't you think it is already overcomplicated?

If I understood correctly, the closest thing I know of to what you are describing is probably Terra:

https://terralang.org/

It is an academic project with various papers presenting case studies that do things like change the whole programming paradigm the language, or the execution model, or the syntax.

The wider paradigm is called multi-stage programming. The other obvious languages to mention are the lisp family, and more recent spin-offs like Julia.

Linting

This is called linting

Isn't that what configure, make and makefiles are for?

https://en.m.wikipedia.org/wiki/Unix_philosophy