Есть в программировании такая концепция — "символы", или "атомы".
Вот например в языке Julia.
Вроде простая концепция, не какие-нибудь монады
Но я никак не могу понять "use cases". Зачем они, какие задачи решают?
Или они возможны только в интерпретируемых языках, а я пытаюсь мысленно прикрутить их к привычным компилируемым типа С/С++ и потому не нахожу применения?
Или их все-же можно прикрутить и к компилируемым языкам тоже?

Здравствуйте, x-code, Вы писали:

XC>Есть в программировании такая концепция — "символы", или "атомы".
XC>Вот например в языке Julia.
XC>Вроде простая концепция, не какие-нибудь монады
XC>Но я никак не могу понять "use cases". Зачем они, какие задачи решают?
XC>Или они возможны только в интерпретируемых языках, а я пытаюсь мысленно прикрутить их к привычным компилируемым типа С/С++ и потому не нахожу применения?
XC>Или их все-же можно прикрутить и к компилируемым языкам тоже?

Я в своем языке на одном этапе использовал атомы как составляющие для базовых типов — чисел, строк. Т.е. базовые типы не были примитивными, а были перечислениями "1 | 2 | ..." и т.п.
Потом, правда, я от этой идеи отказался.
Можно еще атомы использовать в роли членов перечислений (в языке должна быть структурная типизация).

Здравствуйте, x-code, Вы писали:

XC>Есть в программировании такая концепция — "символы", или "атомы".
XC>Вот например в языке Julia.
XC>Вроде простая концепция, не какие-нибудь монады
XC>Но я никак не могу понять "use cases". Зачем они, какие задачи решают?

An atom is a constant whose value is its own name.

Отсюда: https://elixir-lang.org/getting-started/basic-types.html#atoms

XC>Или они возможны только в интерпретируемых языках, а я пытаюсь мысленно прикрутить их к привычным компилируемым типа С/С++ и потому не нахожу применения?
XC>Или их все-же можно прикрутить и к компилируемым языкам тоже?

Я не думаю что такая концепция имеет смысл в статически типизированных языках. В то же время в динамике смысл есть. Например у тебя есть JSON, который ты хочешь диссериализовать. В простейшем случае ты получаешь словарь где в качесве ключа у тебя строка. Ну, жить можно, но никаких проверок и помощи от IDE что ты не опечатался.

iex: Poison.Parser.parse!(~s({"name": "Devin Torres", "age": 27}), %{})
%{"name" => "Devin Torres", "age" => 27}

Но ключи могут быть не только строками, но и атомами, что в целом удобнее в процессе разработки.

iex: Poison.Parser.parse!(~s({"name": "Devin Torres", "age": 27}), %{keys: :atoms!})
%{name: "Devin Torres", age: 27}

В той же BEAM у атомов есть свои подводные камни связанные с реализацией, но к данному вопросу это не относится.

Здравствуйте, x-code, Вы писали:

XC>Есть в программировании такая концепция — "символы", или "атомы".
XC>Или их все-же можно прикрутить и к компилируемым языкам тоже?

Возьмем компилируемый ЯП типа C#. Да, можно. Там это находится в сборке System.Linq под видом Expression.

Здравствуйте, kaa.python, Вы писали:

KP>Но ключи могут быть не только строками, но и атомами, что в целом удобнее в процессе разработки.
KP>

KP>iex: Poison.Parser.parse!(~s({"name": "Devin Torres", "age": 27}), %{keys: :atoms!})
KP>%{name: "Devin Torres", age: 27}
KP>

Получается что атомы должны быть предварительно объявлены. Но можно предварительно объявить и обычные константные строки с именами.
А если атомы не объявляются предварительно — то что мешает ошибиться и при написании атома в виде литеральной строки?

Здравствуйте, x-code, Вы писали:

XC>Получается что атомы должны быть предварительно объявлены. Но можно предварительно объявить и обычные константные строки с именами.

Не обязательно, их можно на лету из строки создать и конвертировать обратно в строку..

XC>А если атомы не объявляются предварительно — то что мешает ошибиться и при написании атома в виде литеральной строки?

Иметь константы которые может проверить компилятор всегда удобнее чем не иметь их. Тут главное то, что атомы наиболее широкое распространение получили в динамически типизированных языках, т.к. в итоге хочется получить хоть чуть чуть бонусов от статический типизации.

Здравствуйте, kaa.python, Вы писали:
KP>Иметь константы которые может проверить компилятор всегда удобнее чем не иметь их. Тут главное то, что атомы наиболее широкое распространение получили в динамически типизированных языках, т.к. в итоге хочется получить хоть чуть чуть бонусов от статический типизации.
Эмм, а чем они отличаются от элементов перечислимых типов в тех жа С++? Ну, кроме того, что они динамические, как и всё остальное?

Здравствуйте, Sinclair, Вы писали:

S>Эмм, а чем они отличаются от элементов перечислимых типов в тех жа С++? Ну, кроме того, что они динамические, как и всё остальное?

Собственно всё. Я же говорю, за пределами динамики в них смысла нет, да и Enum-ы из Python как по мне так более адекватны с описательной точки зрения. Но плюсы в виде генерации на лету и использовании в виде констант всё же присутствуют.

Здравствуйте, kaa.python, Вы писали:

KP>Я не думаю что такая концепция имеет смысл в статически типизированных языках. В то же время в динамике смысл есть. Например у тебя есть JSON, который ты хочешь диссериализовать. В простейшем случае ты получаешь словарь где в качесве ключа у тебя строка. Ну, жить можно, но никаких проверок и помощи от IDE что ты не опечатался.

Для этого давно схемы придумали, которые IDE понимают, а библиотеки умеют проверять. Куда более универсальный инструмент, независимый от языка.

Здравствуйте, ути-пути, Вы писали:

УП>Для этого давно схемы придумали, которые IDE понимают, а библиотеки умеют проверять. Куда более универсальный инструмент, независимый от языка.

Крайне неудобный вариант, так же никак не помогающий на этапе компиляции.