Expression problem: Difference between revisions

Revision as of 07:43, 5 October 2023

Revision as of 14:53, 8 December 2023

Line 1:

{{Short description|Data abstraction problem in programming languages}}

The '''expression problem''' is a challenging problem in [[programming language]]s that concerns the extensibility and modularity of statically typed data abstractions. The goal is to define a data abstraction that is extensible both in its representations and its behaviors, where one can add new representations and new behaviors to the data abstraction, without recompiling existing code, and while retaining static type safety (e.g., no casts). The statement of the problem exposes deficiencies in [[programming paradigm]]s and [[programming language]]s, and {{as of|2023|lc=y}} is still considered unsolved,{{cncitation needed|date=October 2023}} although there are many proposed solutions.{{cncitation needed|reason=feels misleading as if there is some buzz of research interest or activity, whereas in fact most of the references are from 30 years ago|date=October 2023}}

== History ==

Line 41:

applied Reynold's idea in the context of Objects and Abstract Data Types, which had both grown extensively. Cook identified the matrix of representations and behaviors that are implicit in a Data Abstraction, and discussed how ADTs are based on the behavioral axis, while Objects are based on the representation axis. He provides extensive discussion of work on ADTs and Objects that are relevant to the problem. He also reviewed implementations in both styles, discussed extensibility in both directions, and also identified the importance of static typing.

Most importantly, he discussed situations in which there was more flexibility than

Reynolds considered, including internalization and optimization of methods.

At ECOOP '98, [[Shriram Krishnamurthi]] et al.<ref name="Synth">

Line 47:

| title=Synthesizing Object-Oriented and Functional Design to Promote Re-Use

| url=https://cs.brown.edu/~sk/Publications/Papers/Published/kff-synth-fp-oo/

}}</ref> presented a design pattern solution to the problem of simultaneously extending an expression-oriented programming language and its tool-set. They dubbed it the "expressivity problem" because they thought programming language designers could use the problem to demonstrate the expressive power of their creations. For PLT, the problem had shown up in the construction of DrScheme, now [[Racket_Racket (programming_languageprogramming language)#DrRacket_IDEDrRacket IDE|DrRacket]], and they solved it<ref name="FF">

{{cite journal

| title= Modular object-oriented programming with units and mixins

| date=1999 | doi=10.1145/291251.289432 | url= http://dl.acm.org/citation.cfm?id=289432

| last1=Findler | first1=Robert Bruce | last2=Flatt | first2=Matthew | journal=ACM SigplanSIGPLAN Notices | volume=34 | pages=94–104 }}</ref> via a rediscovery of [[mixin]]s.<ref name="Mixins">{{cite thesis |type= PhD

| last= Cook | first= William | date= 1989

| title= A Denotational Semantics of Inheritance | publisher= Brown University