Nikelandjelo Apr 30 2013 at 15:24

edn: extensible data notation

5 min

10K

Lisp*

From sandbox

+22

Comments 30

gaelpa Apr 30 2013 at 19:31

Еще есть Yaml.

ingspree Apr 30 2013 at 21:08

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

gaelpa May 1 2013 at 01:47

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

UFO landed and left these words here

gaelpa May 4 2013 at 20:59

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

Nikelandjelo May 5 2013 at 01:56

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

gaelpa May 7 2013 at 17:32

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

Nikelandjelo May 7 2013 at 17:49

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

UFO landed and left these words here

RockPresident May 1 2013 at 12:59

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

1ex Apr 30 2013 at 22:20

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

Nikelandjelo Apr 30 2013 at 22:25

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

1ex Apr 30 2013 at 22:50

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

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

anjensan May 13 2013 at 18:08

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

monolithed Apr 30 2013 at 23:23

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

{"map": {}}

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

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

{{} : {}}

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

murr Apr 30 2013 at 23:57

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

argos Apr 30 2013 at 23:52

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

Nikelandjelo Apr 30 2013 at 23:58

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

argos May 1 2013 at 00:21

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

Nikelandjelo May 1 2013 at 00:25

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

tonsky Jun 10 2013 at 20:13

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

andll May 1 2013 at 00:22

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

Nikelandjelo May 1 2013 at 00:24

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

argos May 28 2013 at 14:21

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

tonsky Jun 10 2013 at 20:14

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

andll Jun 10 2013 at 22:46

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

StreetStrider Apr 29 2014 at 01:00

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

edn is a system for the conveyance of values.

и далее

…Nor is it a system for representing objects…

github.com/edn-format/edn

StreetStrider Apr 29 2014 at 00:53

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

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

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

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

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

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

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

Nikelandjelo Apr 29 2014 at 01:18

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

StreetStrider Apr 29 2014 at 00:57

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

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

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