Analysis  Requirements & Principles 
architecture: Paradigms 
substance: Abstractions 
structure: Domains  building blocks: Features 
surface: Syntactics  Defining PLs 
Language List  
foundational  safety  flexibilized  

Quick links to the syntactic definition of some languages (some PL grammars): Ada95, Java, Haskell, SML. Modula2.
TODO: Main directions of programm representation:
Concrete syntax:
statements  expressions (+/ sideeffects)  

As a flow chart (1946/47)
Sorry for this crude character graphic  true .> [a]_{v} > <p> +> `> [b]^ false  
In Lisp (1958)  (if (p) (a) (b))  
In Algol60 (1960)  if p then a else b  
In BCPL (end of 1960s) [ref]  test p then a else b
if p then a (in certain cases then may be omitted)  p> a, b 
In C (1971/2/3)  if(p) a else b  p? a : b 
In ML (1978)  if p then a else b  
In Smalltalk80 (1980)  (p) ifTrue: a; ifFalse: b 
Concrete syntax:
notation  schema  examples  occurance 

Function style:  F(A1, ..., An)  pow(2,3)  mathematics, Algolfamily 
Cambridge Polish [Scott]  F A1 ... An  (pow 2 3), (+ x y), (set! x y)  lambdacalculus, Lisp (always surrounded by parantheses), ML, Haskell 
 f A1  x, ¬true, ++x  mathematics, logic, Algolfamily 
Postfix (unary postA1)  A1 f  x!, x^ (pointer dereferencing), x++  mathematics, Pascal, Cfamily 
Infix (binary postA1)  A1 f A2
in Ada syntactic sugar for functionstyle "f"(A1,A2) in C++ syntactic sugar for operatorf(A1,A2) or for A1.operatorf(A2)  x + y, x < y, x & y, x mod y, x>y, (x := y  "application" of "updateoperator"?)  mathematics, logic, Algolfamily 
Selection style  A1.f(A2, ..., An)  x.add(y)  Simulafamily (Eiffel, C++, Java, ...) 
Mixfix styles:  preposition style  myBox displayOn: myScreen at: 100@50
HouseholdFinances spend: 12+20 on: 'food' ages at: 'Brett' put: 3  Smalltalk's keyword messages 
conjunction style  if x then y else z  Algol, ML, Haskell  
circumfix (unary)  x  mathematics  
A2circumfix (binary)  x[y]  Algolfamily  
A2circumfix (ternary)  x ? y : z  Cfamily (C, C++, Java) 
Precedence levels (and associativity) regulate how to parse nested expressions cotaining infix, and/or pre and postfix operators. Infix operators have associated predicende levels and associativity (left/right) to implicitly structure complex expressions. The design question is whether at all and how many different (classes of) operators there should be in the language.
Fortran  C  Ada  

arithmetic  **  post++, ,  ** abs not 
pre++, , unary+, , &, * (ref/deref), !, ~ (logical/bitwise not)  
*, /  *, /, %  *, /, mod, rem  
unary+,   
+,   +,   +, , & (concatentation)  
<<, >> (shift)  
relational  .eq., .ne., .lt., .le., .gt., .ge.  >, >=, <, <=  =, /=, <, <=, >, >= 
==, !=  
bitwise  &  
^  
  
logical  .not.  &&  and, or, xor [or has 'and' higher prec?] 
.and.  
.or.    
.eqv., .neqv.  
conditional  ?:  
asssignment  (?)  =, +=, /=, <<=, &=, ...  (?) 
Argument on the design of Pascal's levels 
«In the interest of simplicity and efficient translatability, Pascal aimed at a reasonably small number of operator precedence levels. Algol 60's hierarchy of 9 levels seemed clearly too baroque. An additional incentive for change was the replacement of the equivalence operator for Boolean expressions ["=" with three line] by the equality operator [normal "="]. Since these two operators reside on different priority levels in Algol 60, some departure from the old rules were mandatory. In retrospect, however, the decision seems illadvised, particularly with the growing significance of complicated Boolean expressions in connection with program verification.» [Niklaus Wirth: An Assessment of the P.L Pascal; SE 1(2) 1975] 
Variation  Argument 
"{...}" vs. keywords  "{...}" is easier to learn, whereas "if...endif", "do...od", "function f...end f;" etc allows better error detection [Anatomy, 59ff]. Also "{...}" is easier to spot on skimming than names (visual); bracketing check support by texteditors more likely than with keywords [IMHO]. 
Assignments:  Meaning  Form 
Definitions:  Meaning  Form 
line terminated  bracketed  nesting  

In Lisp (1958) and assembly  ; comment  
In Algol60 (1960)  comment comment ;  ?  
In Basic (1965)  rem comment  
In Prolog (1972)  % comment  /* comment */  ? 
In BCPL (end of 1960s) [ref]  // comment
 comment \\ comment  /* comment */
* comment * \* comment *\  no nesting of equals (as in Pascal) 
In C (1971/2/3),
linecomment since ISOC, taken from C++  // comment  /* comment */  first closes all: /* ... /* ... /* ... ... */ 
In Pascal (1972)  (* comment *) { comment }  no nesting of equals: (* ... { ... } ... *) { ... (* ... *) ... }  
In ML/SML (1978/83?)   comment  (* comment *)  ? 
In Smalltalk80 (1980) (and earlier versions?)  "comment"  ?  
In Haskell   comment  { comment }  ? 
Variation  Argument 
line terminated vs. bracketed  line terminated comments are less errorprone than bracketed comments [Anatomy, 62ff] 
[ST80] Adele Goldberg, David Robson: Smalltalk80: The Language and its Implementation; AddisonWesley; 1983.
Syntactic sugars are surface structure constructs which can be macroexpressed by other constructs of the language (they are not orthogonal to the rest of the language).
Sugar  Description  Argument 
a<b<=c and similar combinations  equivalent to a<b & b<=c
e.g. in BCPL or Icon  conciseness, common usage 
point free notation:
function f = g
in the context of, e.g., function g(x) = 2*x
 stands for
function f(x) = g(x)
 conciseness 
different loop constructs in the same language  ...  the trend seem in PL design to reduce the variation in loop constructs 
message cascading as in Smalltalk80  Sends a cascade of messages to the same object:
OrderedCollection new add:1; add:2; add:3
Instead of
 cleaner [ST80] 
Feature  Property  Argument 
Tabular notation
linear notation Parnas tables represent relationships and functions in tabular form, AND/OR tables represent boolean formulae (in disjunctive normal form). E.g. (p1 /\ not p3) \/ (p4) \/ (p2 /\ p3) = p1: T . . p2: . . T p3: F . T p4: . T .  readability for documentation (in initial development, design reviews, maintenance ...)  Linear: ``Standard mathematical notation works well
for short formulas, but not for long ones. ...
Hierachical structuring and modularity along are not sufficient.
The problem is that the standard mathematical notation is,
in principle, linear.
This makes it poorly readable when many cases have to be considered.''
Tabular: ``... the most readable definition [of a function with many cases] is that ... where the concept of a table is used.'' [ParnasTables] ``It is interesting that both DNGS and TCAS found tabular representations of information most useful for review and reasoning, as opposed to expressions used in MGS, SACEM, and some of the commercial cases.'' [FormalInInd] 
readability for nonprogrammers (as guarding conditions on state transitions)  Linear (predicate calculus)
``Our TCAS [aircraft collision avoidance system]
external reviewers (including avionics engineers,
component engineers, airline representatives, and pilots),
... did not find this notation natural or reviewable.''
Tabular: ``we decided to use a tabular representation [instead] ...'' [RSML]  
lexical nesting
abstract nesting  errorprone  ``when a nested expression has too many [lexical] nesting levels, humans tend to become confused about the meaning of the code.'' ``Declarations are used ... to reduce the apparent nesting depth of expressions.'' ``Subroutines are used to minimize the depth of [lexical] nesting in a single program unit.'' [Anatomy, 200] 
let
anonymous function with arguments  errorprone  The letconstruct has better lexical coherence than applying an anonymous function to immedeatly following arguments. ``This lack of lexical coherence makes it awkward and error prone for a human to match up the names with the values ...'' [Anatomy, 30] 
Analysis  Requirements & Principles  Paradigms  Abstractions  Domains  Features  foundational  safety  flexible typing  Syntactics  Defining PLs  Language List 