Expression-oriented programming language: Difference between revisions

Revision as of 04:58, 24 April 2010

Latest revision as of 07:57, 4 February 2025

(74 intermediate revisions by 47 users not shown)

Line 1:

{{Notability|date=July 2022}}

{{Programming paradigms}}An '''expression-oriented programming language''' is a [[programming language]] where (nearly) every construction is an [[expression (programming)|expression]] and thus yields a value. The typical exceptions are [[Macro (computer science)|macro]] definitions, [[preprocessor]] commands, and declarations, which expression-oriented languages often treat as [[statement (programming)|statement]]s rather than expressions. Some expression-oriented languages introduce a [[void return type]] to be yielded by expressions that merely cause [[Side_effect_(computer_science)|side-effects]].

An '''expression-oriented programming language''' is a [[programming language]] in which every (or nearly every) construction is an [[Expression (computer science)|expression]] and thus yields a value.<ref>{{Cite web |title=Glossary - The Rust Programming Language |url=https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/glossary.html#expression-oriented-language |access-date=2022-07-06 |website=web.mit.edu}}</ref> The typical exceptions are [[Macro (computer science)|macro]] definitions, [[preprocessor]] commands, and [[Declaration (computer programming)|declarations]], which expression-oriented languages often treat as [[Statement (computer science)|statements]].

[[ALGOL 68]] is an example of an expression-oriented language. [[Pascal programming language|Pascal]] is ''not''. All [[functional programming language]]s are expression-oriented.

[[Lisp (programming language)|Lisp]]<ref name=":0">{{Cite journal |last1=Syme |first1=Don |date=2020-06-14 |title=The early history of F# |journal=Proceedings of the ACM on Programming Languages |language=en |volume=4 |issue=HOPL |pages=1–58 |doi=10.1145/3386325 |issn=2475-1421 |doi-access=free}}</ref> and [[ALGOL 68]] are expression-oriented languages. [[Pascal (programming language)|Pascal]] is not an expression-oriented language.

==Canonical Objection==

All [[functional programming]] languages are expression-oriented.<ref>{{Cite web |author1=Knoldus |date=2018-02-08 |title=Expression Oriented Programming |url=https://medium.com/knoldus/expression-oriented-programming-d88f621fd3a4 |access-date=2023-08-07 |website=Knoldus – Technical Insights |language=en}}</ref>

Critics<ref>[[Assignment_(computer_science)#Assignment_versus_equality|Assignment versus equality]]</ref><ref>[[Relational_operator#Confusion_with_assignment_operators|Confusion with assignment operators]]</ref>, including language designers<ref>[http://java.sun.com/docs/codeconv/html/CodeConventions.doc9.html#547 Java Code Conventions "10.4 Variable Assignments"]</ref>, blame expression-orientation for an entire class of [[software bug|programming mistake]] wherein the programmer introduces an [[Assignment_(computer_science)|assignment expression]] where he meant to test for [[Equality_(relational_operator)|equality]]. For example, the designers of [[Ada_(programming_language)|Ada]] and [[Java_(programming_language)|Java]] were so worried about this type of mistake, they restricted [[Conditional_(programming)|control expressions]] to those that evaluate strictly to the [[Boolean_data_type|boolean data type]].<ref>[http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#5991 Java Language Specification "14.9 The if Statement"]</ref><ref>[http://www.adaic.org/whyada/intro4.html Introducing Ada]</ref> [[Python_(programming_language)|Python]] takes the alternative strategy of implementing assignment as a statement rather than an expression, thus prohibiting assignment from nesting inside of any other statement or expression.<ref>[http://docs.python.org/reference/simple_stmts.html#assignment The Python Language Reference "6.2. Assignment statements"]</ref> Here is an example of one phrasal of the allegation:

==Criticism and prevention==

<blockquote>Expression-orientation can be confusing in [[imperative programming language]]s, as many commands used normally as statements are in fact expressions. For example, assignment in the [[C (programming language)|C programming language]] is an expression, not a statement. This allows for the following confusion:

{{Synthesis|date=July 2022}}

<source lang=c>if (x = 1) {

{{See also|Assignment (computer science)#Assignment versus equality|Relational operator#Confusion with assignment operators}}

...

Critics, including language designers,<ref>[https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html#547 Java Code Conventions "10.4 Variable Assignments"]</ref>{{Failed verification|date=July 2022}} blame expression-orientation for an entire class of [[software bug|programming mistakes]] wherein a programmer accidentally codes an [[Assignment (computer science)|assignment]] ''expression'', which replaces a variable with an expression rather than testing it for [[Equality (relational operator)|equality]] with that expression.

} else {

/* this branch is never executed */

}</source>

The condition of the '''if''' is the result of the expression <code>x = 1</code>, which is 1. Thus the if will always execute the true branch. The above is often confused with:

<source lang=c>if (x == 1) {

... /* executed if x is 1 */

} else {

... /* executed if x is not 1 */

}</source></blockquote>

The designers of [[Ada (programming language)|Ada]] and [[Java (programming language)|Java]] prevent this type of mistake by restricting [[Conditional (computer programming)|control expressions]] to those that evaluate strictly to the [[boolean data type]].<ref>[https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.9 The Java Language Specification, Java SE 8 Edition "14.9 The if Statement"]</ref><ref>[https://www.adaic.org/learn/materials/intro/part4/ Introducing Ada]</ref>

However, we understand the root of such mistakes better if we blame [[notation]] rather than [[semantics]].<ref>[http://xahlee.org/cmaci/notation/trad_math_notation.html The Problems of Traditional Math Notation]</ref> From the perspective of expression-orientation, the choice of [[Assignment_(computer_science)|assignment notation]] made by [[Curly_bracket_programming_language|C-style languages]], the notorious [[equals sign]], &ldquo;=&rdquo;, is a poor choice for multiple reasons, not the least of which is that it encourages programmers to misuse the misleading verb &ldquo;equals&rdquo; when they recite a program&rsquo;s logic in oral English, instead of the more informative verb &ldquo;gets&rdquo;. Most relevant to the present discussion, the equals sign&rsquo;s similarity to, and hazardously small (inadequate) [[Typing#Minimum_string_distance_error_rate|typing distance]]<ref group="nb" name="distance">In fact, considering the automatic repetition feature of [[Keyboard_(computing)|typical computer keyboards]], the [[Typing#Minimum_string_distance_error_rate|minimum string distance]] between [[Assignment_(computer_science)|'''=''']] and [[Equality_(relational_operator)#Equality|'''==''']] is effectively zero, the ''worst possible'' collision.</ref> from the notation C-style languages choose for the equality operator, &ldquo;==&rdquo;, make it an occasion for error. The expression-ness of assignment is not the culprit here. Other language families make better notational choices for assignment<ref>{{Cite web

| last = Rigaux

| first = Pascal

| authorlink = http://merd.sourceforge.net/pixel/cv.html

| title = Syntax Across Languages: ''Assignment or Declaration''

| work = Language Study

| publisher = SourceForge

| date = 2008-08-29 08:32:23

| url = http://merd.sourceforge.net/pixel/language-study/syntax-across-languages.html#VrsVrbssgOrDcl

| format = html

| accessdate = 2010-04-17}}</ref>, such as <code>''variable'' ← ''expression''</code> in [[APL (programming language)|APL]] or <code>''variable'' <- ''expression''</code> in [[Objective Caml]], [[S (programming language)|S]], and [[R (programming language)|R]]. It is also possible to dispense with the assignment operator entirely, as in [[Lisp (programming language)|Lisp]] and [[Scheme (programming language)|Scheme]]&rsquo;s <code>(setq ''variable'' ''expression'')</code>.

The designers of [[Python (programming language)|Python]] implemented assignment as a statement rather than an expression, thus prohibiting assignment from nesting inside any other statement or expression.<ref>[https://docs.python.org/3/reference/simple_stmts.html#assignment The Python Language Reference "6.2. Assignment statements"]</ref> (Until version 3.8 added 'assignment expressions', with a different syntax.<ref>[https://www.python.org/dev/peps/pep-0572/ "PEP 572: Assignment Expressions"]</ref>)

== Notes ==

<references group="nb" />

In some expression-oriented languages, expressions that merely cause [[side effect (computer science)|side effects]] return [[void type]]s.

==Examples==

{{More citations needed|date=July 2022}}

{{Expand section|date=February 2018}}

*[[ALGOL 68]]

*[[BLISS]]

*[[Icon (programming language)|Icon]]

*[[Lisp (programming language)|Lisp]]<ref name=":0" />

*[[ML (programming language)|ML]]

*[[Perl]]

*[[Rebol]]

*[[Ruby (programming language)|Ruby]]

*[[Elixir (programming language)|Elixir]]

*[[Erlang (programming language)|Erlang]]

*[[Haskell]]

*[[Rust (programming language)|Rust]]<ref>{{Cite web |title=Functions - The Rust Programming Language |url=https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/functions.html#expressions-vs-statements |access-date=2022-07-06 |website=web.mit.edu}}</ref>

*[[Scala (programming language)|Scala]]

*[[Smalltalk]]

*[[Kotlin (programming language)|Kotlin]]

*[[OCaml]]<ref>{{Cite web |title=COS 326: Functional Programming |url=https://www.cs.princeton.edu/~dpw/courses/cos326-12/notes/type-check.php |access-date=2022-07-06 |website=www.cs.princeton.edu}}</ref>

<!-- *[[PHP]]<ref>[https://www.php.net/manual/en/language.expressions.php PHP Manual "Expressions"]</ref> -- See talks. PHP manual saying something does not really mean that it is true =( -->

==See also==

*[[Command–query separation]]

*[[Functional programming]]

==References==

{{Reflist}}

{{DEFAULTSORT:Expression-Oriented Programming Languagesparadigms navbox}}

[[Category:Programming language classification]]