[Erlang 0018] Why does Erlang have a special liking for list?

In Erlang programming practice, most of the time is dealing with the list: Taking the Header element, traversing, matching... Why does Erlang and other functional programming languages have a special liking for the list? The referential transparency is referenced in Appendix B of Erlang and OTP in action ).

The following text is excerpted from Wikipedia:

Referential transparencyAndReferential opaquenessAre properties of parts of computer programs. an expression is said to be referentially transparent if it can be replaced with itsvalue without changing the behavior of a program (in other words, yielding a program that has the same effects and output on the same input ). the opposite term is referentially opaque.[Definition]

While in mathematics all function applications are referentially transparent, in programming this is not always the case. the importance of referential transparency is that it allows theprogrammer and the compiler to reason about program behavior. this can help in proving correctness, simplifying an algorithm, processing ing in modifying code without breaking it, oroptimizing Code by means of memoization, common subexpression elimination or parallequalation.[Benefits]

Referential transparency is one of the principles of functional programming; only referentially transparent functions can be memoized (transformed into equivalent functions which cache results ). some programming versions provide means to guarantee referential transparency. some functional programming extensions ages enforce referential transparency for all functions.[Relationship with functional programming]

As referential transparency requires the same results for a given set of inputs at any point in time, a referentially transparent expression is therefore deterministic by definition.

Http://en.wikipedia.org/wiki/Referential_transparency_ (computer_science)

Let's explain the above text first.Definition: If an expression can be replaced by its value, it references transparent; in other words, a program has the same output for the same input, and it references transparent; <Erlang
And OTP in
Action> the definition is more specific: Given a variable X and the value of the variable X, the value of X will not change. Obviously, the single-assignment of Erlang) this ensures the transparency of references. reference transparentBenefits? This book mentions three points (1) to reduce errors
(2) easier parallelization (3) easier memory management and multi-threading, because no write permission is available for existing data.
The third point can be compared. net garbage collection and Erlang garbage collection, Erlang does not appear in the case of old data holding new data reference. more benefits are listed in Wikipedia. You can continue to click here for additional reading.

As mentioned above, referencing transparency is one of the principles of functional programming. What is the relationship between all these and list? Let's look at an example:

Now there is a list l = [1, 2, 3, 4, 5, 6, 7, 8, 9]
To make reference transparent, we can only add elements in the L header, not the end, because if we can do so, other l Reference holders will find that an element is inexplicably added. adding data to the header can keep the original list intact. this operation is highly efficient, and the complexity is O (1 ).

The following is a copy of the book:

Getting back to lists, this referential transparency
Guarantee means that if you already have a list (maybe you got it as an argument
To a function), you can't add elements to the end of that list, because if
You did, then anybody who had a reference to it wocould discover that an extra
Last element had materialized from nowhere. That's not allowed in
Erlang.
But adding to the left (using list cells) is no problem, because
Original list is never disturbed-you create a new cell that points to the first
Cell of the original list, saying "I'm like that list over there, but
This new element added to the head ."
Hence, list cells are an elegant solution to
Problem of growing lists dynamically in a referentially transparent system; and
The implementation is so simple that cells work very efficiently indeed.
Extends extremely clever people have tried (for decades) to come up with a solution
That wocould allow both adding to the end and lower memory usage while
Preserving the transparency property, but those solutions have tended to be both
Very complicated to implement and less efficient in the general case.

At the application level, a single assignment has ensured that the reference is transparent. The above explanation has been made from the perspective of the underlying implementation, and it is now stopped here.

 

 

This is why you may have heard Erlang is said to suck at string manipulation: There is no built-in string type like in most other ages. this is because of Erlang's origins as a language created and used by telecom companies. they never (or rarely) used strings and as such, never felt like adding them officially. however, most of Erlang's lack of sense in string manipulations is getting fixed with time: the VM now natively supports Unicode strings, and overall gets faster on string manipulations all the time.

 

There is also a way to store strings as a binary data structure, making them really light and faster to work. all in all, there are still some functions missing from the standard library and while string processing is definitely doable in Erlang, there are somewhat better versions ages for tasks that need lots of it, like Perl or Python.