In this answer to a previous question of mine about scripting languages suitability as shells, DigitalRoss identifies the difference between the macro languages and the "parsed typed" languages in terms of string treatment as the main reason that scripting languages are not suitable for shell purposes. Macro languages include nroff and m4 for example.

What are the design decisions (or compromises) needed to create a macro programming language? And why are most of the mainstream languages parsed rather than macro?

This very similar question (and the accepted answer) covers fairly well why the parsed typed languages, take C for example, suffer from the use of macros. I believe my question here covers different grounds:

  1. Macro languages or those working on a textual level are not wholly failures. Arguably, they include bash, Tcl and other shell languages. And they work in a specific niche such as shells as explained in my links above. Even m4 had a fairly long time of success, and some of the web template languages can be regarded as macro languages.

  2. It is quite possible that macros and parsed typing do not go well together and that is why macros "break" common languages. In the answer to the linked question, a macro like #define TWO 1+1 would have been covered by the common rules of the language rather than conflicting with those of the host language. And issues like "macros are not typed" and "code doesn't compile" are not relevant in the context of a language designed as untyped and interpreted with little concern for efficiency.

  3. The question about the design decisions needed to create a macro language pertain to a hobby project which I am currently working on on designing a new shell. Taking the previous question in context would clarify the difference between adding macros to a parsed language and my objective.

I hope the clarification shows that the question linked doesn't cover this question, which is two parts:

  1. If I want to create a macro language (for a shell or a web template, for example), what limitations and compromises (and guidelines, if exist) need to be done?

  2. (Probably answerable by a link or reference) Why have no macro languages succeed in becoming mainstream except in particular niches? What makes typed languages successful in large programming, while "stringly-typed" languages succeed in shells and one-liner like environments?

  • 1
    Right there at the top of the related questions is Why aren't macros included in most modern programming languages?; the accepted answer to that question addresses "why are most of the mainstream languages parsed rather than macro?" Commented Mar 10, 2012 at 14:10
  • @AidanCully: I can't say I agree with that. The question linked answers the reason macros are not used as part of parsed typed languages. In particular, the questions I posed do show that many shell languages are effectively macro, and they work (seemingly). Again, my question is what is lost (and what is gained) by creating an untyped language based on textual rewriting. For a special case, think why bash works despite being not parsed typed. Commented Mar 11, 2012 at 16:26
  • @MuhammadAlkarouri Re-opened, thanks for taking the time to clarify how your question is different than the duplicate.
    – yannis
    Commented Mar 12, 2012 at 9:18
  • To answer "What are the design decisions (or compromises) needed to create a macro programming language? ", To get good answers, you need to tell us WHY do you need create a new language. The 'why' part would influence the answer.
    – NoChance
    Commented Apr 11, 2012 at 12:30

1 Answer 1


The linked questions identify a load of issues in current macro languages. If you're going to design a new language, you should address those those issues.

For instance, take the define TWO 1+1; TWO*TWO=3 example. You can make your language robust by not including a rule for 1+1*1+1; instead require arithmetic expressions to be explicitly parenthesized. That means 1+1*1+1 is a syntax error, and should be written as (1+1)*(1+1).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.