Further I find { } silly. Everyone in their right mind indents. Count indentation from the leftmost character of the previous line. Either eliminate tabs as valid within programs or give them some standard meaning like a tab takes you to the nearest 4's boundary.That's fine as long as you write the program.
I often have to generate programs. In particular, I don't even generate the programs itself, but generate a pre-program that uses refinements to specify the bits and pieces that gets inserted in a common skeleton. (E.g., literate programming systems like noweb or nuweb may be (mis)used for that.) Preprocessors create the actual program that gets compiled.
In such circumstances it's a Bad Thing(tm) if white space in general (and
particularly indentation) is used to specify control flow. It would get
messed up much too often.
Unless the system you are using is aware of the problems and can work
around them, but that does require a more specialised system, that knows
about the specific languages (or at least the (syntactic) kinds of languages)
it is being used with.
The markup language crowd learned it's lesson long ago: Please, no optical markup. Add explicit tags to your document. Why don't we stay with that?
The resulting source file gets saved, compiled, tested, and checked in to the configuration management system. Often there's a rule forbidding running the source file through a formatting tool like indent(1) to regularize the indents because that messes up the number-of-lines-changed metrics produced when the files are checked in.
Inferring flow control from indent level just does not work in practice in a multi-programmer, multi-editor multi-display-format situation.
[indentation syntax makes it hard to generate programs]Could you provide some more details? I've heard this argument before, but it's not clear to me that it would be any harder to generate N tabs than to generate block delimiters correctly. How hard is it to keep a global tab counter?
Even if you're just pasting blocks of code together randomly, you must
have some notion of enclosing context, right? FWIW, I _have_ generated code
for an indentation-based language (Python),
with no problems at all. Perhaps you have some unique constraints (?)
Right, but a general system has to be tailored to take it into
account, modifying each line in turn rather than just getting the {...}
brackets right.
The markup language crowd learned it's lesson long ago: Please, no optical markup. Add explicit tags to your document. Why don't we stay with that?But why must writing programs be like writing a document with a markup language? IMHO, we already have plenty of problems with maintainability as it is.
The point is that compilers should be able to use all the information communicated by the programmer (indentation, end-lines), rather than forcing extra, error-prone tokens.
Of course, YMMV; but I've seen many people become addicted to this syntax system, after using it.
It's convenient to use refinements when one generates programs. (There exist processors for them.) While generating one does not necessarily know the current lexical level. I don't think one should be forced to track it if not necessary, just because the language designer thought one *must* indent properly. OTOH, I'll virtually shoot any programmer working for me who does not indent properly.
Another example is the run-time generation of programs as strings that are evaluated later. It's more convenient to create a Lisp-like (i.e., fully parenthesized) structure -- and I think convenience is a very important point in language usage. It allows the programmer to focus on the problem at hand, not at the language quirks. (I'm not a friend of C and C++, can you tell? :-)
Or take as an example the generation of Makefiles. Here you have a language format where indentation and empty lines are important. (Even tabs are important.) Again one has to pay lots of attention in getting the quirks right, time that would be better spent working on solutions to the real problem...
Hope I expressed myself clearer this time,
Please don't tell me one should use other target languages & CM tools. Technical matters are only one (and most often minor) point in the selection of languages & tools for a project.