Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are lots of books about good web design, UI design, etc. With the advent of Xtext, it's very simple to write your own language. What are good books and resources about language design?

I'm not looking for a book about compiler building (like the dragon book) but something that answers:

  • How to create a grammar that is forgiving (like adding optional trailing commas)?
  • Which grammar patterns cause problems for users of a language?
  • How create a compact grammar without introducing ambiguities. Here, think "clean language", not "parser builder warnings". Maybe "how do I avoid confusing the developer using my language?"
share|improve this question

closed as off-topic by MichaelT, durron597, gnat, enderland, Ixrec Oct 18 '15 at 18:40

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Community, durron597, gnat, enderland, Ixrec
If this question can be reworded to fit the rules in the help center, please edit the question.

I'd skip the last list point, as it is a technical issue treated in traditional compiler literature. The others instead sound more like you are interested to create a good language from a usage perspective. Users of a language don't really care much about its grammar's compactness. – Frank Mar 20 '12 at 12:46
I strictly look at the problem from the consumer point of view. So I want to create grammars which are unlike C++/Perl where the reader has make guesses what some code does. – Aaron Digulla Mar 20 '12 at 16:44
Anecdote: Creator of Python is a mathematician and is reflected in the design (clean to read, one way to do etc.) The creator of Perl is linguist (more than one way to do etc.) - so either your background will influence the design or the domain or the need/pain point - you have to know lex/yacc like tools and have a basic understanding of 'how to create a language' - your peers/community members should provide initial feedback on the implementation :) – PhD Mar 20 '12 at 17:24
A tiny tip (it does not worth a full answer, just a comment): never start designing your language from its syntax. Syntax should be the last thing you're implementing for a language. Always design semantics first. – SK-logic Mar 20 '12 at 17:53

In designing language syntax, you have such a wide range of choices that it's really a matter of taste, not engineering. If you want a tried, tested, and familiar syntax, rip off a language or three of your choice. If you want to explore and invent something new, the range of potential pitfalls is also so wide that existing examples may not help.

There's a long tradition of comparative language design books, which present a selection of contemporary languages -- with commentary, but generally not much in the way of conclusions. Nonetheless, you could do worse than to find a university engineering library and go through a few of them.

Also, keep in mind that grammar is arguably the least important aspect of the language. More important aspects include: the type system, the module system, support of large systems, issues of name scope, abstraction, semantics, resource management, concurrency, et cetera.

Addition: Principles of Language Design and Evolution is a web-available article on programming language design (ca. 1999) by Bertrand Meyer, the designer of Eiffel.

It focuses on simplicity and consistency, but with a pragmatic edge. Interestingly, Meyer's take on syntax is that it actually matters quite a bit. Aside from the practical aspect of supporting actual users, he notes that unsatisfactory syntax is frequently a pointer to deeper, semantic problems.

share|improve this answer

I'm not aware of a canonical book. That may be because design best practices are likely to be domain-specific. A language for mathematicians should look very math-like, a language for chemists should look very chemistry-like, etc. Some things that make no sense in one domain are essential in another.

For example, I write software for networking equipment, which has its own language for configuration. The command for shutting down a port is, intuitively enough, shutdown. However, the command for enabling a port is no shutdown. To me, that's the stupidest design ever, but it's very natural for our users from a historical perspective.

Keep in mind, unless you're squarely in the target demographic, you're probably the worst person to design the language. You will tend to want something with an efficient grammar, or easy implementation, or consistency with programming languages you know, but the user doesn't care about those things. Start out by reading something an end user has written, and consider your job to be refinement of that based on criteria like parseability, consistency, and removing ambiguity.

For example, I'm currently working on a language for keeping track of all the numbers associated with pen and paper roleplaying games. Rather than starting with the grammar, or looking at other programming languages I could adapt, I started by looking at how those numbers are described in existing published rule books. They have a lot of phrases like "-2 penalty to armor class when cowering," so that's what my syntax looks like, with words like penalty, to, and when being keywords. There are obviously some restrictions necessary to make it readable by computer, but most of the time a user is going to be able to copy directly from a rule book with only minor modifications.

share|improve this answer

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