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.
–
FrankMar 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 DigullaMar 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 :)
–
PhDMar 20 '12 at 17:24

2

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-logicMar 20 '12 at 17:53

2 Answers
2

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.

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.

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.