Is the concept of an algebraic data type close to class definitions in OO languages?

Both concepts allow you to create new data types. The only difference that I see is that in functional languages ​​you can match patterns by algebraic data types. But for OO languages ​​there is no comparable concise function. Is this an exact statement?

+6
source share
4 answers

I see three main differences between algebraic data types and OO classes, apart from (im) mutablility, because it changes.

  • Algebraic data types allow you to get sums as well as products, while classes of the OO class only allow products.
  • Classes of the OO class allow combining a complex data element with its accepted operations, while algebraic data types do not.
  • Algebraic data types do not distinguish between data passed to the constructor and data stored in the resulting value, while OO-style classes (or can).

One thing that I specifically missed from this list was subtyping. Although the vast majority of OO languages ​​allows you to subclass (incomplete, non-printable, currently available) classes, but the vast majority of functional languages ​​do not have a common ML level, it’s obvious that you can prohibit inheritance entirely in hypothetical OO (or at least OO- similar) language, and it is also possible to create subtypes and supertypes in algebraic data types; for a limited example of the latter, see this page in O'Haskell , which Timber succeeded

+3
source

Algebraic data types are named so because they form "initial algebra",

+ represents sum types (disjoint unions, eg Either). • represents product types (eg structs or tuples) X for the singleton type (eg data X a = X a) 1 for the unit type () and μ for the least fixed point (eg recursive types), usually implicit. 

from these operators can be built all the usual data types. Algebraic data types also support parametric polymophism, which means that they can be used as constants for any basic type with static security guarantees. In addition, ADTs have a single syntax for introducing and eliminating data types (through constructors and pattern matching). For instance.

 -- this defines a tree data Tree a = Empty | Node a (Tree a) (Tree a) -- this constructs a tree let x = Node 1 (Node 2 Empty) Empty -- this deconstructs a tree f (Node alr) = a + (fl) + (fr) 

The richness and uniformity of the types of algebraic data, as well as the fact that they are immutable, distinguishes them from OO objects, which are largely:

  • represent only product types (therefore no recursive or summarized types)
  • do not support pattern matching
  • are mutable
  • do not support parametric polymorphism
+8
source

A class is more than just a type definition. Classes in most OO languages ​​are indeed kitchen sink functions that provide all kinds of loosely coupled functions.

In particular, classes act as a kind of module, providing you with data abstraction and a namespace. Algebraic data types do not have a built-in module; modularity is usually provided as a separate orthogonal function (usually modules).

+3
source

In a sense, it can be seen like this. In every language, there are so many mechanisms for creating custom types. In functional (ML, Haskell style) languages, the only one is the creation of ADT. (A new type of Haskell can be seen as a degenerate case of ADT). In OO languages, these are classes. In procedural languages, this is a struct or record .

It goes without saying that the semantics of a user-defined data type differ from language to language, and even more so from language in paradigm No. 1 to language in paradigm No. 2. @Pharien Flame has already identified typical differences.

+3
source

Source: https://habr.com/ru/post/915255/


All Articles