Jump to content

Programming language specification: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Replaced "alphabet" with "specific character set"
Qreligious (talk | contribs)
160 edits
m Added citation. Removed double spaces. Minor punctuation updates for clarity and consistency.
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]] 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==
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").


{{cquote|ALGOL 68 was the first (and possibly one of the last) major language for which a full formal definition was made before it was implemented.|4=[[Cornelis H. A. Koster|C.H.A. Koster]]|5=<ref name="ashoa68">{{cite web | title = A Shorter History of Algol68 | url = http://npt.cc.rsu.ru/user/wanderer/ODP/ALGOL68.txt | accessdate = September 15, 2006 |archiveurl = https://web.archive.org/web/20060810103448/http://npt.cc.rsu.ru/user/wanderer/ODP/ALGOL68.txt <!-- Bot retrieved archive --> |archivedate = August 10, 2006}}</ref>}}
{{cquote|ALGOL 68 was the first (and possibly one of the last) major language for which a full formal definition was made before it was implemented.|4=[[Cornelis H. A. Koster|C.H.A. Koster]]|5=<ref name="ashoa68">{{cite web | title = A Shorter History of Algol68 | url = http://npt.cc.rsu.ru/user/wanderer/ODP/ALGOL68.txt | accessdate = September 15, 2006 |archiveurl = https://web.archive.org/web/20060810103448/http://npt.cc.rsu.ru/user/wanderer/ODP/ALGOL68.txt <!-- Bot retrieved archive --> |archivedate = August 10, 2006}}</ref>}}
Line 24: Line 24:
| year = 1997
| year = 1997
| isbn = 0-262-63181-4}}</ref> and [[Scheme (programming language)|Scheme]]<ref>{{cite web|first=Richard |last=Kelsey |author2=William Clinger |author3=Jonathan Rees|title=Section 7.2 Formal semantics|work=Revised<sup>5</sup> Report on the Algorithmic Language Scheme|url = http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.2|date=February 1998|accessdate=2006-06-09}}</ref> specifications). A notable example is the C language, which gained popularity without a formal specification, instead being described as part of a book, ''[[The C Programming Language]]'' (1978), and only much later being formally standardized in [[ANSI C]] (1989).
| isbn = 0-262-63181-4}}</ref> and [[Scheme (programming language)|Scheme]]<ref>{{cite web|first=Richard |last=Kelsey |author2=William Clinger |author3=Jonathan Rees|title=Section 7.2 Formal semantics|work=Revised<sup>5</sup> Report on the Algorithmic Language Scheme|url = http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.2|date=February 1998|accessdate=2006-06-09}}</ref> specifications). A notable example is the C language, which gained popularity without a formal specification, instead being described as part of a book, ''[[The C Programming Language]]'' (1978), and only much later being formally standardized in [[ANSI C]] (1989).
* A description of the behavior of a [[compiler]] (sometimes called "translator") for the language (e.g., the [[C++]] language and [[Fortran]]). The syntax and semantics of the language has to be inferred from this description, which may be written in natural or a formal language.
* A description of the behavior of a [[compiler]] (sometimes called "translator") for the language (e.g., the [[C++]] language and [[Fortran]]). The syntax and semantics of the language has to be inferred from this description, which may be written in natural or a formal language.
* A [[reference implementation|''model'' implementation]], sometimes written in the language being specified (e.g., [[Prolog]]). The syntax and semantics of the language are explicit in the behavior of the model implementation.
* A [[reference implementation|''model'' implementation]], sometimes written in the language being specified (e.g., [[Prolog]]). The syntax and semantics of the language are explicit in the behavior of the model implementation.


==Syntax==
==Syntax==
{{Expand section|date=February 2018}}
{{Expand section|date=February 2018}}
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:


* A specific character set (non-empty, finite set of symbols)
* A specific character set (non-empty, finite set of symbols)
Line 48: Line 48:
* '''[[Natural language]]''': Description by human natural language.
* '''[[Natural language]]''': Description by human natural language.
* '''[[Formal semantics of programming languages|Formal semantics]]''': Description by [[mathematics]].
* '''[[Formal semantics of programming languages|Formal semantics]]''': Description by [[mathematics]].
* '''[[Reference implementation]]s''': Description by [[computer program]]
* '''[[Reference implementation]]s''': Description by [[computer program]].
* '''[[Test suite]]s''': Description by examples of programs and their expected behaviors. While few language specifications start off in this form, the evolution of some language specifications has been influenced by the semantics of a test suite (e.g. in the past the specification of [[Ada (programming language)|Ada]] has been modified to match the behavior of the [[Ada Conformity Assessment Test Suite]]).
* '''[[Test suite]]s''': Description by examples of programs and their expected behaviors. While few language specifications start off in this form, the evolution of some language specifications has been influenced by the semantics of a test suite (e.g., in the past the specification of [[Ada (programming language)|Ada]] has been modified to match the behavior of the [[Ada Conformity Assessment Test Suite]]).


===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.
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>


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 60: Line 60:
Formal semantics are grounded in mathematics. As a result, they can be more precise and less ambiguous than semantics given in natural language. However, supplemental natural language descriptions of the semantics are often included to aid understanding of the formal definitions. For example, The [[International Organization for Standardization|ISO]] Standard for [[Modula-2]] contains both a formal and a natural language definition on opposing pages.
Formal semantics are grounded in mathematics. As a result, they can be more precise and less ambiguous than semantics given in natural language. However, supplemental natural language descriptions of the semantics are often included to aid understanding of the formal definitions. For example, The [[International Organization for Standardization|ISO]] Standard for [[Modula-2]] contains both a formal and a natural language definition on opposing pages.


Programming languages whose semantics are described formally can reap many benefits. For example:
Programming languages whose semantics are described formally can reap many benefits. For example:
* Formal semantics enable mathematical proofs of program correctness;
* Formal semantics enable mathematical proofs of program correctness;
* Formal semantics facilitate the design of [[type system]]s, and proofs about the soundness of those type systems;
* Formal semantics facilitate the design of [[type system]]s, and proofs about the soundness of those type systems;
* Formal semantics can establish unambiguous and uniform standards for implementations of a language.
* Formal semantics can establish unambiguous and uniform standards for implementations of a language.


Automatic tool support can help to realize some of these benefits. For example, an [[automated theorem prover]] or theorem checker can increase a programmer's (or language designer's) confidence in the correctness of proofs about programs (or the language itself). The power and scalability of these tools varies widely: full [[formal verification]] is computationally intensive, rarely scales beyond programs containing a few hundred lines{{Citation needed|date=February 2007}} and may require considerable manual assistance from a programmer; more lightweight tools such as [[model checker]]s require fewer resources and have been used on programs containing tens of thousands of lines; many compilers apply static [[type system|type checks]] to any program they compile.
Automatic tool support can help to realize some of these benefits. For example, an [[automated theorem prover]] or theorem checker can increase a programmer's (or language designer's) confidence in the correctness of proofs about programs (or the language itself). The power and scalability of these tools varies widely: full [[formal verification]] is computationally intensive, rarely scales beyond programs containing a few hundred lines{{Citation needed|date=February 2007}} and may require considerable manual assistance from a programmer; more lightweight tools such as [[model checker]]s require fewer resources and have been used on programs containing tens of thousands of lines; many compilers apply static [[type system|type checks]] to any program they compile.


===Reference implementation===
===Reference implementation===
A [[reference implementation]] is a single implementation of a programming language that is designated as authoritative. The behavior of this implementation is held to define the proper behavior of a program written in the language. This approach has several attractive properties. First, it is precise, and requires no human interpretation: disputes as to the meaning of a program can be settled simply by executing the program on the reference implementation (provided that the implementation behaves deterministically for that program).
A [[reference implementation]] is a single implementation of a programming language that is designated as authoritative. The behavior of this implementation is held to define the proper behavior of a program written in the language. This approach has several attractive properties. First, it is precise, and requires no human interpretation: disputes as to the meaning of a program can be settled simply by executing the program on the reference implementation (provided that the implementation behaves deterministically for that program).


On the other hand, defining language semantics through a reference implementation also has several potential drawbacks. Chief among them is that it conflates limitations of the reference implementation with properties of the language. For example, if the reference implementation has a bug, then that bug must be considered to be an authoritative behavior. Another drawback is that programs written in this language may rely on quirks in the reference implementation, hindering portability across different implementations.
On the other hand, defining language semantics through a reference implementation also has several potential drawbacks. Chief among them is that it conflates limitations of the reference implementation with properties of the language. For example, if the reference implementation has a bug, then that bug must be considered to be an authoritative behavior. Another drawback is that programs written in this language may rely on quirks in the reference implementation, hindering portability across different implementations.


Nevertheless, several languages have successfully used the reference implementation approach. For example, the [[Perl]] interpreter is considered to define the authoritative behavior of Perl programs. In the case of Perl, the [[open-source model]] of software distribution has contributed to the fact that nobody has ever produced another implementation of the language, so the issues involved in using a reference implementation to define the language semantics are moot.
Nevertheless, several languages have successfully used the reference implementation approach. For example, the [[Perl]] interpreter is considered to define the authoritative behavior of Perl programs. In the case of Perl, the [[open-source model]] of software distribution has contributed to the fact that nobody has ever produced another implementation of the language, so the issues involved in using a reference implementation to define the language semantics are moot.


===Test suite===
===Test suite===
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 &mdash; 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, it is difficult to use a test suite to 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.
Line 88: Line 88:
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:
**[http://www.masswerk.at/algol60/report.htm Algol 60 report]
**[http://www.masswerk.at/algol60/report.htm Algol 60 report]

Revision as of 22:34, 6 November 2024

In computer programming, a programming language specification (or standard or definition) is a documentation artifact that defines a programming language so that users and 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

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.[1] 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").

ALGOL 68 was the first (and possibly one of the last) major language for which a full formal definition was made before it was implemented.

— C.H.A. Koster, [2]

Forms

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

  • An explicit definition of the syntax and 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 language), or a formal semantics (e.g., the Standard ML[3] and Scheme[4] specifications). A notable example is the C language, which gained popularity without a formal specification, instead being described as part of a book, The C Programming Language (1978), and only much later being formally standardized in ANSI C (1989).
  • A description of the behavior of a compiler (sometimes called "translator") for the language (e.g., the C++ language and Fortran). The syntax and semantics of the language has to be inferred from this description, which may be written in natural or a formal language.
  • A model implementation, sometimes written in the language being specified (e.g., Prolog). The syntax and semantics of the language are explicit in the behavior of the model implementation.

Syntax

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 specific character set (non-empty, finite set of symbols)
  • Regular expressions describing its 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 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

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[5]

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.[6]

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 threads were specified in English, and it was later discovered that the specification did not provide adequate guidance for implementors.[7]

Formal semantics

Main article: Formal semantics of programming languages

Formal semantics are grounded in mathematics. As a result, they can be more precise and less ambiguous than semantics given in natural language. However, supplemental natural language descriptions of the semantics are often included to aid understanding of the formal definitions. For example, The ISO Standard for Modula-2 contains both a formal and a natural language definition on opposing pages.

Programming languages whose semantics are described formally can reap many benefits. For example:

  • Formal semantics enable mathematical proofs of program correctness;
  • Formal semantics facilitate the design of type systems, and proofs about the soundness of those type systems;
  • Formal semantics can establish unambiguous and uniform standards for implementations of a language.

Automatic tool support can help to realize some of these benefits. For example, an automated theorem prover or theorem checker can increase a programmer's (or language designer's) confidence in the correctness of proofs about programs (or the language itself). The power and scalability of these tools varies widely: full formal verification is computationally intensive, rarely scales beyond programs containing a few hundred lines[citation needed] and may require considerable manual assistance from a programmer; more lightweight tools such as model checkers require fewer resources and have been used on programs containing tens of thousands of lines; many compilers apply static type checks to any program they compile.

Reference implementation

A reference implementation is a single implementation of a programming language that is designated as authoritative. The behavior of this implementation is held to define the proper behavior of a program written in the language. This approach has several attractive properties. First, it is precise, and requires no human interpretation: disputes as to the meaning of a program can be settled simply by executing the program on the reference implementation (provided that the implementation behaves deterministically for that program).

On the other hand, defining language semantics through a reference implementation also has several potential drawbacks. Chief among them is that it conflates limitations of the reference implementation with properties of the language. For example, if the reference implementation has a bug, then that bug must be considered to be an authoritative behavior. Another drawback is that programs written in this language may rely on quirks in the reference implementation, hindering portability across different implementations.

Nevertheless, several languages have successfully used the reference implementation approach. For example, the Perl interpreter is considered to define the authoritative behavior of Perl programs. In the case of Perl, the open-source model of software distribution has contributed to the fact that nobody has ever produced another implementation of the language, so the issues involved in using a reference implementation to define the language semantics are moot.

Test suite

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.

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

Language specifications

A few examples of official or draft language specifications:

Notes

  1. ^ Announcing a specification for PHP, July 30, 2014, Joel Marcey
  2. ^ "A Shorter History of Algol68". Archived from the original on August 10, 2006. Retrieved September 15, 2006.
  3. ^ Milner, R.; M. Tofte; R. Harper; D. MacQueen (1997). The Definition of Standard ML (Revised). MIT Press. ISBN 0-262-63181-4.
  4. ^ Kelsey, Richard; William Clinger; Jonathan Rees (February 1998). "Section 7.2 Formal semantics". Revised5 Report on the Algorithmic Language Scheme. Retrieved 2006-06-09.
  5. ^ Jones, D. (2008). Forms of language specification (PDF). Retrieved 2012-06-23.
  6. ^ Gosling, James; Joy, Bill; Steele, Guy; Bracha, Gilad (June 2005). "The Java Language Specification, Third Edition". Addison-Wesley Longman.
  7. ^ William Pugh. The Java Memory Model is Fatally Flawed. Concurrency: Practice and Experience 12(6):445-455, August 2000
Retrieved from "https://en.wikipedia.org/w/index.php?title=Programming_language_specification&oldid=1255839232"