{a -> x, b -> y, c -> z} /. List -> Association
(*<|a -> x, b -> y, c -> z|>*)


The opposite cannot be performed:

<|a -> x, b -> y, c -> z|> /. Association -> List
(*<|a -> x, b -> y, c -> z|>*)


Any idea why?

• Associationis an Atom whereas List is not. – RunnyKine Jul 27 '14 at 18:28
• Do you mean I can not replace Atom by head? – Basheer Algohi Jul 27 '14 at 18:35
• Exactly. Try replacing the head of an Integer or Real – RunnyKine Jul 27 '14 at 18:36
• I tried this Sin[3] /. Sin -> e and I got e[3] and then i did e[3]/.e->List I got {3}. – Basheer Algohi Jul 27 '14 at 18:40
• If you are interested to convert an Association to a list you can use Normal... – unlikely Jul 27 '14 at 19:32

Mathematica knows two types of expressions: compound expressions and atomic expressions.

For example, in

Plus[1, x]


Plus, 1 and x are atomic. They are used to construct a compound expression Plus[1,x].

General expression manipulation, such as extracting or changing parts or replacing parts does not work on atomic expressions. That's because they're "atomic", i.e. indivisible, they do not have parts.

This is why you can't replace the head of an Association: it does not have a head, as it does not have any parts.

AtomQ can be used to test if an expression is atomic.

To be more precise, the situation is a bit more complicated in practice. Some atomic objects do have a full form which looks like a compound expression. E.g. Complex[1, 2] looks like it has head Complex, and parts 1 and 2. When you enter this expression, it is indeed a compound expression made of these three parts. However, it will immediately evaluate to a truly atomic expression, which means that Complex[1, 2] /. Complex -> complex won't work.

To make the situation even more complicated, some atomic objects do have some support for manipulating and extracting "parts", e.g. you can index a SparseArray. Consider this as a special support. Each type of atomic object is different and each of them support different kinds of manipulations.

The general guideline is to consider atomic objects indivisible.

• Thanks for your explanation. One more thing and it will be clear, suppose I have Complex[1, 2], is there any other way to do this: Complex[1, 2]/.Complex[1, 2]->{1,2}?. if you can elaborate on this on your answer that will be great. – Basheer Algohi Jul 27 '14 at 19:53
• @Algohi Use Re and Im. – Michael E2 Jul 27 '14 at 20:47
• @Algohi As Michael said, for various atomic objects there are usually some functions to extract data from them. For Complex this is Im and Re. You might notice that MatchQ[Complex[1, 2], Complex[_, _]] is True and it is possible to do Complex[1, 2] /. Complex[i_, j_] :> {i, j}. This often causes confusion. It is important to realize that this works just because this specific functionality happens to be implemented for Complex. It does not mean that Complex has a generally accessible internal structure, e.g. List @@ Complex[1, 2] doesn't work. – Szabolcs Jul 27 '14 at 23:09
• This is really interesting... is it possible to invent your own atomic object, and make your own functions that extract/manipulate their data? – QuantumDot Dec 22 '14 at 22:36
• @QuantumDot "Atomic" here means that it doesn't work like typical expressions and users can't dissect the object. So technically no, by definition. But a similar situation arises when you write code to access a data structure implemented in C through LibraryLink. In this case usually you'd have a plain Mathematica expression that holds some sort of reference to the C side object. When you use Managed Library Expressions (please search docs for examples, I can't easily link it), this reference is just an integer. – Szabolcs Dec 22 '14 at 23:10