Expression-oriented programming language: Difference between revisions

Content deleted Content added
Chmarkine (talk | contribs)
m Criticism: change to https if the server sends HSTS header, replaced: http://docs.python.org → https://docs.python.org using AWB
this original synthesis remained uncited almost two years; does not belong in article
Line 6:
 
Critics<!--[[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 a programmer introduces an [[Assignment (computer science)|assignment expression]] where they 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]].<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> The designers of [[Python (programming language)|Python]] had similar worries but took 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>[https://docs.python.org/reference/simple_stmts.html#assignment The Python Language Reference "6.2. Assignment statements"]</ref>
 
However, [[notation]] provokes such errors, not [[semantics]].{{uncited|date=July 2014}} From the perspective of expression-orientation, the choice of [[Assignment (computer science)|assignment notation]] made by [[Curly bracket programming language|C-style languages]], the [[equals sign]], <code>=</code>, can be considered a poor choice due to the equals sign's similarity to, and hazardously small [[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 <code>[[Assignment (computer science)|=]]</code> and <code>[[Equality_(relational_operator)#Equality|==]]</code> is effectively zero, the ''worst possible'' collision.</ref> from the notation C-style languages choose for the equality operator, <code>==</code>, make it an occasion for error. The expression-ness of assignment is not the root cause. Other language families make different notational choices for assignment<ref>{{Cite web
| last = Rigaux
| first = Pascal
| 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
| accessdate = 2010-04-17}}</ref> that do not have this problem, such as <code>''variable'' ← ''expression''</code> in [[APL (programming language)|APL]], <code>''variable'' <- ''expression''</code> in [[OCaml]], [[S (programming language)|S]], and [[R (programming language)|R]], <code>''variable'' := ''expression''</code> in [[ALGOL 68]] and [[Standard ML]], or <code>(setq ''variable'' ''expression'')</code> in [[Lisp (programming language)|Lisp]] and [[Scheme (programming language)|Scheme]]. Furthermore, many expression-oriented languages are also functional languages. In these languages, assignment is either rare, or, in the case of [[purely functional]] languages, impossible.
 
==See also==