Is :ok a predefined or reserved keyword in Elixir?

vonH

When looking at the elixir-lang docs on tuples iex> {:ok, "hello"}, tuple = {:ok, "hello"} , I see :ok being introduced out of thin air (unless it is introduced elsewhere), but when I try this sequence

iex -S mix
c "myfuncs/funcs_router.ex"
{:df, _} = Plug.Adapters.Cowboy.http MyRouter, []

I get the error report
** (MatchError) no match of right hand side value: {:ok, #PID<0.185.0>}

so I assume that :ok is a special atom. I can see atoms like :nil, :true and :false. Is there a list of special atoms in Elixir that can’t be used elsewhere?

8 comments

#keyword #how-to-question

0 3012 8

2018-07-05 13:50:05 UTC

Marked As Solved

Show Best Posts
Show All (oldest first)
Show All (newest first)

RobinSJ

:ok is a atom, like all other atoms it will not be garbage collected.

The reason you’re getting a match error, is because the Plug.Adapters.Cowboy.http.MyRouter function will return a tuple in the format of {:ok, pid} (This is very common in Erlang/Elixir).

The tuple {:df, _} will not match the tuple {:ok, pid} because the atoms are different

Post #1

Also Liked

OvermindDL1

Atoms are compiled into the code when loaded in the VM (not at compile-only time), if an :ok is in code then it is statically defined. In essence this happens:

Code is loaded into the VM
The VM runs passes over the code
One of those passes looks at atoms, looks up the atom name (up to 255 bytes of basically anything) in the global atom table, if it finds it then it replaces the atom in the source with an integer of the index into that table, if it is not found then it makes a new entry and uses that index
If multiple nodes connect then the first time they communicate any atom between them they creating a mapping of indexes to indexes to make for fast communication

That is why it cannot be garbage collected, it may be used by other nodes once connected, it is used inside the compiled code in the VM, etc…

There are some functions that directly access the atom table, one of those is calling to_string on an atom, it looks up the atom’s index in the atom table and returns the string. Another can get the atom index of a string and create it if it does not exist, and another does the same but will error if it does not exist (always use that one if you need it).

So it does not matter where it is defined or used or anything, every module in every location gets the same atom index. It is only set at VM time, not compile-time.

Post #4

OvermindDL1

Also think of it this way since you implied you use C and such in other posts, think of an atom as a named integer, every one is unique in the system and any of the same name will always match any other very fast. Quite literally at compile time the atom :ok in code is replaced with an integer so the comparisons are integer-fast (though the integer is packed in the tagged type properly, just like integers but a different tag).

Post #2

RobinSJ

Atoms are never assigned any value. You can think of them as constants, where the value of the atom is the name of it. The value of the atom :ok is :ok

With regards to atoms not being garbage collected, every atom declared in the lifetime of a program will be stored in an atom table. If you create atoms dynamically (through user-input), at some point the atom table will consume too much memory and the VM will be killed. This is just something to be aware of

Post #5