Programming language specification - Revision history

2605:A601:A0A4:2700:FC6F:3D02:3FCB:9877 at 11:36, 1 April 2025

2025-04-01T11:36:00Z

← Previous revision		Revision as of 11:36, 1 April 2025
Line 9:		Line 9:

	==Forms==		==Forms==
	A programming language specification can take several forms, including ~~the following~~:		A programming language specification can take several forms, including:

	* An explicit definition of the [[programming language syntax\|syntax]] and [[programming language semantics\|semantics]] of the language. While syntax is commonly specified using a [[formal grammar]], semantic definitions may be written in [[natural language]] (e.g., the approach taken for the [[C (programming language)\|C language]]), or a [[formal semantics of programming languages\|formal semantics]] (e.g., the [[Standard ML]]<ref>{{cite book		* An explicit definition of the [[programming language syntax\|syntax]] and [[programming language semantics\|semantics]] of the language. While syntax is commonly specified using a [[formal grammar]], semantic definitions may be written in [[natural language]] (e.g., the approach taken for the [[C (programming language)\|C language]]), or a [[formal semantics of programming languages\|formal semantics]] (e.g., the [[Standard ML]]<ref>{{cite book
Line 33:		Line 33:
	* A specific character set (non-empty, finite set of symbols)		* A specific character set (non-empty, finite set of symbols)
	* [[Regular expression\|Regular expressions]] describing its [[Lexeme (computer science)\|lexemes]] (for alphabet-wise tokenisation)		* [[Regular expression\|Regular expressions]] describing its [[Lexeme (computer science)\|lexemes]] (for alphabet-wise tokenisation)
	* A [[~~Context~~-free grammar]] which describes how the lexemes may be combined in order to form a correct program		* A [[context-free grammar]] which describes how the lexemes may be combined in order to form a correct program

	Syntax specification generally supposes a natural language description in order to provide modest comprehensibility. However, the formal representation of the above outlined components is usually part of the section as it favors the implementation and approval of the language and its concepts.		Syntax specification generally supposes a natural language description in order to provide modest comprehensibility. However, the formal representation of the above outlined components is usually part of the section as it favors the implementation and approval of the language and its concepts.

	==Semantics==		==Semantics==
	Formulating a rigorous semantics of a large, complex, practical programming language is a daunting task even for experienced specialists, and the resulting specification can be difficult for anyone but experts to understand. The following are some of the ways in which programming language semantics can be described; all languages use at least one of these description methods, and some languages combine more than one<ref>{{cite book		Formulating a rigorous semantics of a large, complex, practical programming language is a daunting task even for experienced specialists, and the resulting specification can be difficult for anyone but experts to understand. The following are some of the ways in which programming language semantics can be described; all languages use at least one of these description methods, and some languages combine more than one.<ref>{{cite book
	\| last = Jones		\| last = Jones
	\| first = D.		\| first = D.
Line 52:		Line 52:

	===Natural language===		===Natural language===
	Most widely used languages are specified using natural language descriptions of their semantics. This description usually takes the form of a ''reference manual'' for the language. These manuals can run to hundreds of pages, e.g., the print version of ''The Java Language Specification, 3rd Ed.'' is 596 pages ~~long~~.<ref>{{Cite web \|last=Gosling \|first=James \|last2=Joy \|first2=Bill \|last3=Steele \|first3=Guy \|last4=Bracha \|first4=Gilad \|date=June 2005 \|title=The Java Language Specification, Third Edition \|url=https://www.researchgate.net/publication/200040359_The_Java_Language_Specification_Third_Edition \|publisher=Addison-Wesley Longman}}</ref>		Most widely used languages are specified using natural language descriptions of their semantics. This description usually takes the form of a ''reference manual'' for the language. These manuals can run to hundreds of pages; e.g., the print version of ''The Java Language Specification, 3rd Ed.'' is 596 pages.<ref>{{Cite web \|last=Gosling \|first=James \|last2=Joy \|first2=Bill \|last3=Steele \|first3=Guy \|last4=Bracha \|first4=Gilad \|date=June 2005 \|title=The Java Language Specification, Third Edition \|url=https://www.researchgate.net/publication/200040359_The_Java_Language_Specification_Third_Edition \|publisher=Addison-Wesley Longman}}</ref>

	The imprecision of natural language as a vehicle for describing programming language semantics can lead to problems with interpreting the specification. For example, the semantics of [[Java (programming language)\|Java]] [[thread (computer programming)\|threads]] were specified in English, and it was later discovered that the specification did not provide adequate guidance for implementors.<ref>William Pugh. The Java Memory Model is Fatally Flawed. ''Concurrency: Practice and Experience'' 12(6):445-455, August 2000</ref>		The imprecision of natural language as a vehicle for describing programming language semantics can lead to problems with interpreting the specification. For example, the semantics of [[Java (programming language)\|Java]] [[thread (computer programming)\|threads]] were specified in English, and it was later discovered that the specification did not provide adequate guidance for implementors.<ref>William Pugh. The Java Memory Model is Fatally Flawed. ''Concurrency: Practice and Experience'' 12(6):445-455, August 2000</ref>
Line 77:		Line 77:
	Defining the semantics of a programming language in terms of a [[test suite]] involves writing a number of example programs in the language, and then describing how those programs ought to behave—perhaps by writing down their correct outputs. The programs, plus their outputs, are called the "test suite" of the language. Any correct language implementation must then produce exactly the correct outputs on the test suite programs.		Defining the semantics of a programming language in terms of a [[test suite]] involves writing a number of example programs in the language, and then describing how those programs ought to behave—perhaps by writing down their correct outputs. The programs, plus their outputs, are called the "test suite" of the language. Any correct language implementation must then produce exactly the correct outputs on the test suite programs.

	The chief advantage of this approach to semantic description is that it is easy to determine whether a language implementation passes a test suite. The user can simply execute all the programs in the test suite, and compare the outputs to the desired outputs. However, when used by itself, the test suite approach has major drawbacks as well. For example, users want to run their own programs, which are not part of the test suite; indeed, a language implementation that could ''only'' run the programs in its test suite would be largely useless. But a test suite does not, by itself, describe how the language implementation should behave on any program not in the test suite; determining that behavior requires some extrapolation on the implementor's part, and different implementors may disagree. In addition, ~~it is difficult to use~~ a test suite to test behavior that is intended or allowed to be [[Nondeterministic programming\|nondeterministic]].		The chief advantage of this approach to semantic description is that it is easy to determine whether a language implementation passes a test suite. The user can simply execute all the programs in the test suite, and compare the outputs to the desired outputs. However, when used by itself, the test suite approach has major drawbacks as well. For example, users want to run their own programs, which are not part of the test suite; indeed, a language implementation that could ''only'' run the programs in its test suite would be largely useless. But a test suite does not, by itself, describe how the language implementation should behave on any program not in the test suite; determining that behavior requires some extrapolation on the implementor's part, and different implementors may disagree. In addition, a test suite cannot easily test behavior that is intended or allowed to be [[Nondeterministic programming\|nondeterministic]].

	Therefore, in common practice, test suites are used only in combination with one of the other language specification techniques, such as a natural language description or a reference implementation.		Therefore, in common practice, test suites are used only in combination with one of the other language specification techniques, such as a natural language description or a reference implementation.

	==See also==
	* [[Programming language reference]]

	==External links==		==External links==
Line 88:		Line 85:
	A few examples of official or draft language specifications:		A few examples of official or draft language specifications:
	*Specifications written primarily in formal mathematics:		*Specifications written primarily in formal mathematics:
	**[http://mitpress.mit.edu/books/definition-standard-ml The Definition of Standard ML, revised edition] – a formal definition in an [[operational semantics]] style.		**[http://mitpress.mit.edu/books/definition-standard-ml The Definition of Standard ML, revised edition] – a formal definition in an [[operational semantics]] style
	**[http://www.schemers.org/Documents/Standards/ Scheme R5RS] – a formal definition in a [[denotational semantics]] style		**[http://www.schemers.org/Documents/Standards/ Scheme R5RS] – a formal definition in a [[denotational semantics]] style
	*Specifications written primarily in natural language:		*Specifications written primarily in natural language:

Qreligious: Added citation. Removed double spaces. Minor punctuation updates for clarity and consistency.

2024-11-06T22:34:12Z

Added citation. Removed double spaces. Minor punctuation updates for clarity and consistency.

Show changes

Sam Tomato: Replaced "alphabet" with "specific character set"

2024-02-21T21:15:14Z

Replaced "alphabet" with "specific character set"

← Previous revision		Revision as of 21:15, 21 February 2024
Line 31:		Line 31:
	The [[syntax]] of a programming language represents the definition of acceptable words, i.e. formal parameters and rules upon which to decide whether a given code is valid in respect to the language. On that note, the language syntax usually consists of a combination of the following three construction components:		The [[syntax]] of a programming language represents the definition of acceptable words, i.e. formal parameters and rules upon which to decide whether a given code is valid in respect to the language. On that note, the language syntax usually consists of a combination of the following three construction components:

	* An ~~alphabet~~ (non-empty, finite set of symbols~~; usually [[Unicode]] characters~~)		* A specific character set (non-empty, finite set of symbols)
	* [[Regular expression\|Regular expressions]] describing its [[Lexeme (computer science)\|lexemes]] (for alphabet-wise tokenisation)		* [[Regular expression\|Regular expressions]] describing its [[Lexeme (computer science)\|lexemes]] (for alphabet-wise tokenisation)
	* A [[Context-free grammar]] which describes how the lexemes may be combined in order to form a correct program		* A [[Context-free grammar]] which describes how the lexemes may be combined in order to form a correct program

	Syntax specification generally supposes a natural language description in order to provide ~~modeste~~ comprehensibility. However, the formal representation of the above outlined components is usually part of the section as it favors the implementation and approval of the language and its concepts.		Syntax specification generally supposes a natural language description in order to provide modest comprehensibility. However, the formal representation of the above outlined components is usually part of the section as it favors the implementation and approval of the language and its concepts.

	==Semantics==		==Semantics==

Kku: link formal grammar

2024-02-16T15:29:47Z

link formal grammar

← Previous revision		Revision as of 15:29, 16 February 2024
Line 11:		Line 11:
	A programming language specification can take several forms, including the following:		A programming language specification can take several forms, including the following:

	* An explicit definition of the [[programming language syntax\|syntax]] and [[programming language semantics\|semantics]] of the language. While syntax is commonly specified using a formal grammar, semantic definitions may be written in [[natural language]] (e.g., the approach taken for the [[C (programming language)\|C language]]), or a [[formal semantics of programming languages\|formal semantics]] (e.g., the [[Standard ML]]<ref>{{cite book		* An explicit definition of the [[programming language syntax\|syntax]] and [[programming language semantics\|semantics]] of the language. While syntax is commonly specified using a [[formal grammar]], semantic definitions may be written in [[natural language]] (e.g., the approach taken for the [[C (programming language)\|C language]]), or a [[formal semantics of programming languages\|formal semantics]] (e.g., the [[Standard ML]]<ref>{{cite book
	\| last = Milner		\| last = Milner
	\| first = R.		\| first = R.

Felida97: Reverted edits by 41.90.64.238 (talk): editing tests (HG) (3.4.9)

2023-06-28T21:29:32Z

Reverted edits by 41.90.64.238 (talk): editing tests (HG) (3.4.9)

← Previous revision		Revision as of 21:29, 28 June 2023
Line 1:		Line 1:
	{{Short description\|Documentation defining a programming language}}		{{Short description\|Documentation defining a programming language}}

	In [[computer programming]], a '''programming language specification''' (or '''standard''' or '''definition''') is a [[~~Documentation Center Nazi Party Rally Grounds\|~~documentation]] artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the [[C++]] specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.		In [[computer programming]], a '''programming language specification''' (or '''standard''' or '''definition''') is a [[documentation]] artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the [[C++]] specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.

	==~~[[Standardizations\|~~Standardization]]==		==Standardization==
	Not all major programming languages have specifications, and languages can exist and be popular for decades without a specification. A language may have one or more implementations, whose behavior acts as a ''de facto'' standard, without this behavior being documented in a specification. [[Perl]] (through [[Perl 5]]) is a notable example of a language without a specification, while PHP was only specified in 2014, after being in use for 20 years.<ref>[http://hhvm.com/blog/5723/announcing-a-specification-for-php Announcing a specification for PHP], July 30, 2014, Joel Marcey</ref> A language may be implemented and then specified, or specified and then implemented, or these may develop together, which is usual practice today. This is because implementations and specifications provide checks on each other: writing a specification requires precisely stating the behavior of an implementation, and implementation checks that a specification is possible, practical, and consistent. Writing a specification before an implementation has largely been avoided since [[ALGOL 68]] (1968), due to unexpected difficulties in implementation when implementation is deferred. However, languages are still occasionally implemented and gain popularity without a formal specification: an implementation is essential for use, while a specification is desirable but not essential (informally, "code talks").		Not all major programming languages have specifications, and languages can exist and be popular for decades without a specification. A language may have one or more implementations, whose behavior acts as a ''de facto'' standard, without this behavior being documented in a specification. [[Perl]] (through [[Perl 5]]) is a notable example of a language without a specification, while PHP was only specified in 2014, after being in use for 20 years.<ref>[http://hhvm.com/blog/5723/announcing-a-specification-for-php Announcing a specification for PHP], July 30, 2014, Joel Marcey</ref> A language may be implemented and then specified, or specified and then implemented, or these may develop together, which is usual practice today. This is because implementations and specifications provide checks on each other: writing a specification requires precisely stating the behavior of an implementation, and implementation checks that a specification is possible, practical, and consistent. Writing a specification before an implementation has largely been avoided since [[ALGOL 68]] (1968), due to unexpected difficulties in implementation when implementation is deferred. However, languages are still occasionally implemented and gain popularity without a formal specification: an implementation is essential for use, while a specification is desirable but not essential (informally, "code talks").

41.90.64.238 at 21:29, 28 June 2023

2023-06-28T21:29:08Z

← Previous revision		Revision as of 21:29, 28 June 2023
Line 1:		Line 1:
	{{Short description\|Documentation defining a programming language}}		{{Short description\|Documentation defining a programming language}}

	In [[computer programming]], a '''programming language specification''' (or '''standard''' or '''definition''') is a [[documentation]] artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the [[C++]] specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.		In [[computer programming]], a '''programming language specification''' (or '''standard''' or '''definition''') is a [[Documentation Center Nazi Party Rally Grounds\|documentation]] artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the [[C++]] specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.

	==Standardization==		==[[Standardizations\|Standardization]]==
	Not all major programming languages have specifications, and languages can exist and be popular for decades without a specification. A language may have one or more implementations, whose behavior acts as a ''de facto'' standard, without this behavior being documented in a specification. [[Perl]] (through [[Perl 5]]) is a notable example of a language without a specification, while PHP was only specified in 2014, after being in use for 20 years.<ref>[http://hhvm.com/blog/5723/announcing-a-specification-for-php Announcing a specification for PHP], July 30, 2014, Joel Marcey</ref> A language may be implemented and then specified, or specified and then implemented, or these may develop together, which is usual practice today. This is because implementations and specifications provide checks on each other: writing a specification requires precisely stating the behavior of an implementation, and implementation checks that a specification is possible, practical, and consistent. Writing a specification before an implementation has largely been avoided since [[ALGOL 68]] (1968), due to unexpected difficulties in implementation when implementation is deferred. However, languages are still occasionally implemented and gain popularity without a formal specification: an implementation is essential for use, while a specification is desirable but not essential (informally, "code talks").		Not all major programming languages have specifications, and languages can exist and be popular for decades without a specification. A language may have one or more implementations, whose behavior acts as a ''de facto'' standard, without this behavior being documented in a specification. [[Perl]] (through [[Perl 5]]) is a notable example of a language without a specification, while PHP was only specified in 2014, after being in use for 20 years.<ref>[http://hhvm.com/blog/5723/announcing-a-specification-for-php Announcing a specification for PHP], July 30, 2014, Joel Marcey</ref> A language may be implemented and then specified, or specified and then implemented, or these may develop together, which is usual practice today. This is because implementations and specifications provide checks on each other: writing a specification requires precisely stating the behavior of an implementation, and implementation checks that a specification is possible, practical, and consistent. Writing a specification before an implementation has largely been avoided since [[ALGOL 68]] (1968), due to unexpected difficulties in implementation when implementation is deferred. However, languages are still occasionally implemented and gain popularity without a formal specification: an implementation is essential for use, while a specification is desirable but not essential (informally, "code talks").

OlliverWithDoubleL: added short description

2022-06-05T07:26:03Z

added short description

← Previous revision		Revision as of 07:26, 5 June 2022
Line 1:		Line 1:
			{{Short description\|Documentation defining a programming language}}
⚫	In [[~~computing~~]], a '''programming language specification''' (or '''standard''' or '''definition''') is a documentation artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the C++ specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.

		⚫	In [[computer programming]], a '''programming language specification''' (or '''standard''' or '''definition''') is a [[documentation]] artifact that defines a [[programming language]] so that [[programmer\|user]]s and [[programming language implementation\|implementors]] can agree on what programs in that language mean. Specifications are typically detailed and formal, and primarily used by implementors, with users referring to them in case of ambiguity; the [[C++]] specification is frequently cited by users, for instance, due to the complexity. Related documentation includes a [[programming language reference]], which is intended expressly for users, and a [[programming language rationale]], which explains why the specification is written as it is; these are typically more informal than a specification.

	==Standardization==		==Standardization==

R.Kumr: Expanded syntax section (a slightly more detail view).

2022-01-25T16:57:09Z

Expanded syntax section (a slightly more detail view).

← Previous revision		Revision as of 16:57, 25 January 2022
Line 27:		Line 27:
	==Syntax==		==Syntax==
	{{Expand section\|date=February 2018}}		{{Expand section\|date=February 2018}}
	The [[syntax]] of a programming language is usually ~~described~~ ~~using~~ a combination of the following ~~two~~ components:		The [[syntax]] of a programming language represents the definition of acceptable words, i.e. formal parameters and rules upon which to decide whether a given code is valid in respect to the language. On that note, the language syntax usually consists of a combination of the following three construction components:

⚫	* a [[~~regular~~ expression]] describing its [[~~lexeme~~ (computer science)\|~~lexeme~~]]s, ~~and~~
			* An alphabet (non-empty, finite set of symbols; usually [[Unicode]] characters)
⚫	* a [[~~context~~-free grammar]] which describes how lexemes may be combined to form a ~~syntactically~~ correct program.
		⚫	* [[Regular expression\|Regular expressions]] describing its [[Lexeme (computer science)\|lexemes]] (for alphabet-wise tokenisation)
		⚫	* A [[Context-free grammar]] which describes how the lexemes may be combined in order to form a correct program

			Syntax specification generally supposes a natural language description in order to provide modeste comprehensibility. However, the formal representation of the above outlined components is usually part of the section as it favors the implementation and approval of the language and its concepts.

	==Semantics==		==Semantics==

Tom.Reding: Enum 2 author/editor WLs; WP:GenFixes on

2020-12-19T18:26:15Z

Enum 2 author/editor WLs; WP:GenFixes on

← Previous revision		Revision as of 18:26, 19 December 2020
Line 12:		Line 12:
	\| last = Milner		\| last = Milner
	\| first = R.		\| first = R.
	\| ~~authorlink~~ = Robin Milner		\| author-link = Robin Milner
			\|author2=M. Tofte
	\|author2=[[Mads Tofte\|M. Tofte]] \|author3=[[Robert Harper (computer scientist)\|R. Harper]] \|author4=D. MacQueen
			\|author2-link=Mads Tofte
			\|author3=R. Harper
			\|author3-link=Robert Harper (computer scientist)
			\|author4=D. MacQueen
	\| title = The Definition of Standard ML (Revised)		\| title = The Definition of Standard ML (Revised)
	\| publisher = MIT Press		\| publisher = MIT Press
Line 31:		Line 35:
	\| last = Jones		\| last = Jones
	\| first = D.		\| first = D.
	\| ~~authorlink~~ = Derek M. Jones		\| author-link = Derek M. Jones
	\| title = Forms of language specification		\| title = Forms of language specification
	\| year = 2008		\| year = 2008
Line 89:		Line 93:

	==Notes==		==Notes==
			{{Reflist}}
	<references/>

	[[Category:Programming language topics\|Specification]]		[[Category:Programming language topics\|Specification]]

Andormaybe: /* Language specifications */ update link to Ruby Spec Suite ( was rubyspec.org which no longer resolves )

2019-10-10T20:06:24Z

Language specifications: update link to Ruby Spec Suite ( was rubyspec.org which no longer resolves )

← Previous revision		Revision as of 20:06, 10 October 2019
Line 86:		Line 86:
	**[http://www.csci.csusb.edu/dick/c++std/cd2/index.html Draft C++ standard]		**[http://www.csci.csusb.edu/dick/c++std/cd2/index.html Draft C++ standard]
	*Specifications via test suite:		*Specifications via test suite:
	**[~~http~~://~~rubyspec~~.~~org~~/ Ruby's de facto community-driven specification]		**[https://github.com/ruby/spec Ruby's de facto community-driven specification]

	==Notes==		==Notes==