edn: extensible data notation

[gaelpa]

Еще есть Yaml.

[ingspree]

Который значительно сложнее и очень хрупкий (из-за значащих отступов).

[gaelpa]

Смотря что вам нужно от формата сериализации. Кто-то вон на питоне и кофе пишет, на отступы вроде не жалуются. В edn зато разделителей в массивах нет.
Насчет сложности, искренне не понимаю чем yaml сложнее edn. Вроде всё то же самое, вид сбоку.

[gaelpa]

Вы, видимо, не в курсе, что валидный json является в то же время валидным yaml документом?

[Nikelandjelo]

Я был не в курсе. Забавно. но спорное преимущество. Писать yaml в json'овом формате это странно. Мне лично yaml немного не нравится тем, что в нём я не могу спокойно, как захочется, писать данные, надо строго следить за отступами. Если редактор поддерживает yaml и сам всё контролирует, то круто, но это не всегда так. Конечно в этом и прелесть yaml'а, что все файлы (конфиги) выглядят однообразно и красиво. Но если что-то на коленке протестировать, как пример с тем же curl'ом (где гарантия, что парсеры yaml'а корректно распарсят json-like формат?). Поэтому с json'ом или edn'ом мне кажется будет проще для таких целей.

[gaelpa]

>> где гарантия, что парсеры yaml'а корректно распарсят json-like формат?
Там же где и гарантия, что они корректно распарсят yaml. Он так устроен, что json является его подмножеством (yaml 1.2).
Если вы не доверяете конкретным реализациям парсера, то это уже другой вопрос.

[Nikelandjelo]

Я сейчас попробовал найти yaml парсер для джавы, который поддерживает 1.2 и сходу не нашёл. Т.е. для спецификации, которой уже больше 3 лет нет реализации на одном из самых популярных языков? Я могу это понять тем, что это не сильно актуально, т.к. мало кто пользуется этими фичами. И следовательно от того, что они есть ни холодно, ни жарко.
Вообще посмотрел на оф сайте, большинство реализуют 1.0 или 1.1: www.yaml.org/

[RockPresident]

Об этом конечно можно много спорить, но я напишу не для этого а просто чтобы ваше безапеляционное заявление не казалось читателям какой-то общеизвестной истиной а тем чем и является — вашим личным мнением, подкреплённым неизвестно чем.
По мне так yaml гораздо проще, ведь он и задумывался как формат с наибольшей удобочитаемостью и чётким пониманием людьми. Теже значащие отступы гарантируют что структуру человек сможет легко воспринять на глаз, потому что они всегда будут соответствовать семантическому уровню данных в документе. Может вы имеете ввиду что его сложнее парсить? Ну это да, так это проблема парсеров, их всё равно почти никто на коленке не пишет…

[1ex]

Может ли в качестве ключа в мапе быть использован обьект?

[Nikelandjelo]

А что вы понимаете под объектом? В качестве ключа может использоваться что угодно, в том числе другая мапа. Возможно nil нельзя использовать.

[1ex]

Имел ввиду как раз «другую мапу». При работе с json приходится дико изворачиваться.

Формат интересный, а теперь вдвойне интересный, спасибо!

[anjensan]

Можно даже так делать
{nil nil}

[monolithed]

При работе с json приходится дико изворачиваться.

{"map": {}}

Где тут дикие извороты?

Или вы хотите писать так?

{{} : {}}

Если да, то теперь самому интересно как это будет выглядеть и обрабатываться

[murr]

Истины ради хочу отметить, что иногда приходится так изголятся, например, когда нужно сериализовать сложный объект в JSON. Ну а объекты в качестве ключей встречаются не так и редко, и предложение нового типа WeakMap тому доказательство.

[argos]

>edn — формат данных, появившийся из языка clojure.
S-exp приблизительно раз в 10 старше самой clojure а plist'ы для представления данных думаю появились вместе с ними.

[Nikelandjelo]

Верю. А как это относится к тому, что edn появился из clojure?

[argos]

к тому что edn это plist

[Nikelandjelo]

Я плохо разбираюсь в истории возникновения лиспов и их синтаксисов. Поэтому я просто написал, что edn пошёл из clojure. Откуда пошёл clojure это другой вопрос, и он тут не раскрывается.

[tonsky]

Ну вы различайте все-таки концепцию и конкретные правила конкретного синтаксиса.

[andll]

Гм, я так расчитывал что хоть в одном более-менее общеизвестном формате появяться back reference.(возможность ссылаться на другой объект внутри документа)
Но в статье про них не упоминается, значит и тут их нет?

[Nikelandjelo]

Нет, их тут нет. Для этого видимо нужно юзать yaml.

[argos]

В нормальной реализации plist (например в Common Lisp) есть backreference:
'(:param1 #1=1 :param2 2 :param3 #1#)

[tonsky]

Нет, и это философская позиция. EDN — формат представления данных, а не объектов и их связей. Backreference бы усложнили понимание, реализацию и сделали бы парсер stateful.

[andll]

Да, пожалуй вы правы. backreference лучше реализовывать на уровне выше парсера, как-то мне это не приходило в голову

[StreetStrider]

Удваиваю оратора выше. Сам автор напирает на это:

edn is a system for the conveyance of values.

и далее

…Nor is it a system for representing objects…

github.com/edn-format/edn

[StreetStrider]

Можно использовать формат UTF8: \u2603.

Вероятно, тут имеется ввиду юникодный литерал, т.е. юникод в целом, а не именно UTF-8. Точно такие символы (четыре шестнадцатеричные цифры) поддерживаются и в JSON, и там тоже о них не говорится, как о UTF-8.

В качестве ключей может выступать любой другой тип.

К слову, в YAML ключи тоже могут быть не скалярного типа. Вероятно, как для YAML, так и для edn большинство реализаций парсера всё таки ограничиваются простыми типами.

Вообще сложно придумать, когда может быть удобнее использовать список, а не вектор.

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

Элементы с тегами это весьма клёвая штука. Сам автор в одной из своих презентаций напирает на важность расширяемости для формата. Как edn, так и YAML поддерживают теги, что позволяет регистрировать в формате свои типы. JSON — нет, и теги приходится симулировать.

[Nikelandjelo]

У меня другое имхо. Для меня вектор и список это 2 очень похожих типа данных с разными характеристиками операций над ними. И я не думаю, что тут список — это record.

[StreetStrider]

Лично мне в edn симпатичен такой простой факт: пары ключи-значения не надо никак разделять. Ключ и значение в мапе определятся чисто по порядку: нечётные элементы это ключи, последующие чётные — их значения. Это очень круто.

С одной стороны мы имеем JSON с его запятой-разделителем и двоеточием внутри пары. Он также не позволяет «висячие» запятые, это означает, что при перестановке-добавлении-удалении элементов легко потерять запятую, или добавить лишнюю.
С другой мы имеем YAML, где всё подвязано на отступы.

Тут нет ни подвязки на разделитель, ни на отступы, да и разделитель внутри пары не нужен. Супер.