Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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?" –  Aidan Cully Mar 10 '12 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. –  Muhammad Alkarouri Mar 11 '12 at 16:26
@MuhammadAlkarouri Re-opened, thanks for taking the time to clarify how your question is different than the duplicate. –  Yannis Rizos Mar 12 '12 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. –  Emmad Kareem Apr 11 '12 at 12:30
add comment

1 Answer

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).

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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