Editing Programming language (section)

===Syntax===
{{Main|Syntax (programming languages)}}
[[File:Python add5 parse.png|thumb|367px|[[Parse tree]] of [[Python (programming language)|Python code]] with inset tokenization]]
[[File:Python add5 syntax.svg|thumb|292px|[[Syntax highlighting]] is often used to aid programmers in recognizing elements of source code. The language above is [[Python (programming language)|Python]].]]
A programming language's surface form is known as its [[syntax (programming languages)|syntax]]. Most programming languages are purely textual; they use sequences of text including words, numbers, and punctuation, much like written natural languages. On the other hand, some programming languages are [[visual programming language|graphical]], using visual relationships between symbols to specify a program.

The syntax of a language describes the possible combinations of symbols that form a syntactically correct program. The meaning given to a combination of symbols is handled by semantics (either [[Formal semantics of programming languages|formal]] or hard-coded in a [[Reference implementation (computing)|reference implementation]]). Since most languages are textual, this article discusses textual syntax.

The programming language syntax is usually defined using a combination of [[regular expression]]s (for [[lexical analysis|lexical]] structure) and [[Backus–Naur form]] (for [[context-free grammar|grammatical]] structure). Below is a simple grammar, based on [[Lisp (programming language)|Lisp]]:
<syntaxhighlight lang="bnf">
expression ::= atom | list
atom       ::= number | symbol
number     ::= [+-]?['0'-'9']+
symbol     ::= ['A'-'Z''a'-'z'].*
list       ::= '(' expression* ')'
</syntaxhighlight>

This grammar specifies the following:
* an ''expression'' is either an ''atom'' or a ''list'';
* an ''atom'' is either a ''number'' or a ''symbol'';
* a ''number'' is an unbroken sequence of one or more decimal digits, optionally preceded by a plus or minus sign;
* a ''symbol'' is a letter followed by zero or more of any alphabetical characters (excluding whitespace); and
* a ''list'' is a matched pair of parentheses, with zero or more ''expressions'' inside it.

The following are examples of well-formed token sequences in this grammar: <code>12345</code>, <code>()</code> and <code>(a b c232 (1))</code>.

Not all syntactically correct programs are semantically correct. Many syntactically correct programs are nonetheless ill-formed, per the language's rules; and may (depending on the language specification and the soundness of the implementation) result in an error on translation or execution. In some cases, such programs may exhibit [[undefined behavior]]. Even when a program is well-defined within a language, it may still have a meaning that is not intended by the person who wrote it.

Using [[natural language]] as an example, it may not be possible to assign a meaning to a grammatically correct sentence or the sentence may be false:
* "[[Colorless green ideas sleep furiously]]." is grammatically well-formed but has no generally accepted meaning.
* "John is a married bachelor." is grammatically [[well-formedness|well-formed]] but expresses a meaning that cannot be true.

The following [[C (programming language)|C language]] fragment is syntactically correct, but performs operations that are not semantically defined (the operation <code>*p >> 4</code> has no meaning for a value having a complex type and <code>p->im</code> is not defined because the value of <code>p</code> is the [[null pointer]]):

<syntaxhighlight lang="c">
complex *p = NULL;
complex abs_p = sqrt(*p >> 4 + p->im);
</syntaxhighlight>

If the [[type declaration]] on the first line were omitted, the program would trigger an error on the undefined variable <code>p</code> during compilation. However, the program would still be syntactically correct since type declarations provide only semantic information.

The grammar needed to specify a programming language can be classified by its position in the [[Chomsky hierarchy]]. The syntax of most programming languages can be specified using a Type-2 grammar, i.e., they are [[context-free grammar]]s.<ref>{{cite book|author=Michael Sipser|year=1996|title=Introduction to the Theory of Computation|publisher=PWS Publishing|isbn=978-0-534-94728-6 |author-link=Michael Sipser|title-link=Introduction to the Theory of Computation}} Section 2.2: Pushdown Automata, pp.101–114.</ref> Some languages, including Perl and Lisp, contain constructs that allow execution during the parsing phase. Languages that have constructs that allow the programmer to alter the behavior of the parser make syntax analysis an [[undecidable problem]], and generally blur the distinction between parsing and execution.<ref>Jeffrey Kegler, "[http://www.jeffreykegler.com/Home/perl-and-undecidability Perl and Undecidability] {{webarchive|url=https://web.archive.org/web/20090817183115/http://www.jeffreykegler.com/Home/perl-and-undecidability |date=17 August 2009 }}", ''The Perl Review''. Papers 2 and 3 prove, using respectively [[Rice's theorem]] and direct reduction to the [[halting problem]], that the parsing of Perl programs is in general undecidable.</ref> In contrast to [[Lisp macro|Lisp's macro system]] and Perl's <code>BEGIN</code> blocks, which may contain general computations, C macros are merely string replacements and do not require code execution.<ref>Marty Hall, 1995, [http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html Lecture Notes: Macros] {{webarchive|url=https://web.archive.org/web/20130806054148/http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html |date=6 August 2013 }}, [[PostScript]] [http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.ps version] {{webarchive|url=https://web.archive.org/web/20000817211709/http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.ps |date=17 August 2000 }}</ref>