Tree как универсальный формат общения программ и людей

Правда текстовые редакторы такое нормально понимать не будут.

Немножко о формате tree.

Ох уж эти отступы (для небольшого текста они еще как-то там «понимаемы»).

Приведите большой XML/JSON, где отступы снановятся непонимаемыми.

Что думаете об этом всём?

Что для простоты, понятности и расширяемости есть EDN, а для быстроты и компактности есть Transit. Единственное применение, которое я вижу для сабжа — это роль личного велосипеда, польза от которого состоит в радости от катания.

Правда, на соучастников я бы в таком случае не рассчитывал: кататься вдвоем на одном велосипеде — такое себе. Да и зачем помогать кататься на его велосипеде кому-то другому, если можно кататься самому на своем собственном? Правда ведь, ТС? %)

Речь шла о формате ТС.

Ну вот я и прошу дать пример XML/JSON который плохо представляется в виде формата ТС.

Формат ТС – прямой конкурент переусложнённого и кривого YAML.

Ну вот я и прошу дать пример XML/JSON который плохо представляется в виде формата ТС.

Представляется, но иерархия определяется отступами.
В небольших текстах их еще как-то можно соблюсти.

Ждём примера большого текста с глубокой иерархией на любом языке разметки который вам больше нравится.

Ждём примера большого текста с глубокой иерархией на любом языке разметки который вам больше нравится.

У меня давно решен этот вопрос (API для использования метаданных).

Свой формат представления файлов и баз метаданных (бинарный).

В частности все форматы Microsoft Office без проблем конвертируются в этот формат (и для этого имеется API).

Ныне ЯП разрабатываю (будет совместим с стандартом C11 и нативная поддержка метаданных).

Он является бинарным, но человекопонятным, но не требует экранирования, но парсится как машиной так и человеком предельно однозначно.

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

Например:

1. Нулевой байт может привести к окончанию чтения или может быть заменён редактором на пробел и т.п..

2. Другие байты < 0x20 могут также быть испорчены редактором при сохранении.

3. Последовательность байт интерпретируемая как UTF-8 может быть искажена.

Возможно стоит добавить поддержку значений кодируемых в Base 64. Например:

image
	name \red dot.png
	data
		!iVBORw0KGgoAAAANSUhEUgAAAAUA
		!AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8
		!/w38GIAXDIBKE0DHxgljNBAAO
		!9TXL0Y4OHwAAAABJRU5ErkJggg==

На всякий случай:

https://faq.treenotation.org/
https://jtree.treenotation.org/designer/
https://github.com/breck7/ctree
https://github.com/dpapathanasiou/go-tree-notation

Велосипед-то еще и краденый, получается? %)

Велосипед-то еще и краденый, получается?

Какая ссылка и что в ней?

Предыдущие посты были ни к тому, чтобы сказать «формат не нужен».

Хотелось бы посмотреть спецификацию бинарного формата.
Ссылка ТС у меня показывает лишь черный экран.

Не хотите помочь с написанием доки, которая даже дураку будет понятна?

Тебе стоит перестать вести себя как несносный подросток, если хочешь помощи.

Не понятно, чем он лучше JSON. Скорость - не аргумент. Я пока не встречал программу, которая упиралась бы в скорость парсинга JSON. Если такие и есть, то это редкий случай и скорей всего в этом случае есть форматы и получше.

XML хватит всем

Ну он же для машины избыточен из-за текстовой природы при этом ещё и человеко-нечитаем.

По стилю изложения - хочется сразу внятно увидеть про сабж, а не продираться через описание и сравнение других форматов. Тем более что версия tree с 2015го вроде как изменилась?

Про сам формат - любое универсальное решение сливает узкоспециализированным в области их специализации. Это аксиома.

Есть скажем формат pickle, он умеет кольцевые ссылки в тч.

Что касается попытки скрестить DSL с форматом данных, да ещё и сверху удобный парсинг натянуть, я такое пробовал. Биндил питоновскую структуру в шелл, так что бы можно было её настраивать через аргументы командной строки/из файла, да ещё и в файл сохранять, и все одним движением. Не взлетело, неудобно.

В Tree и нет никаких строк. Есть только сырые данные. Что вы туда засунете, то и вынете. Строка обычно сериализуется в utf8 бинарник. И как любой бинарник нарезается на список чанков, которые выводятся как есть. Если вам нужно хранить всякие нечитаемые бинарники, но при этом хочется редактировать любым текстовым редактором, то, конечно, лучше на уровне DSL предусмотреть упаковку бинарника в base64.

Какая ссылка и что в ней?

Нет, я понемаю, что по чужим ссылкам ходить не принято, но свои-то собственные ссылки надо хоть раз открыть? %)

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

Сравнивал с этой: https://dlang.org/phobos/std_json.html В статье есть сравнение и с TOML.

А какой браузер? Есть ли ошибки в консоли? Эта статья так же доступна тут: https://github.com/nin-jin/slides/tree/master/tree

Есть скажем формат pickle

Это который в Питоне?

Комментарии и дефолты можете добавить на свой вкус. Например:

; \Точность чего-то там, по умолчанию 16
precision 14

; \Настройки сжатия
zlib
	; \Разрешено ли сжатие выходного потока, по умолчанию выключен
	output_compression +

; \Настройкии рантайма
zend
	; \Включён ли сборщик мусора, по умолчанию включён
	enable_gc +
	;
	; \И так далее
	exception_ignore_args -

Формат INI, разумеется, тоже надо изучать. Описанию формата как раз и посвящён пролог php.ini

Ко грамматикам формат представления AST не имеет никакого отношения, но если вас интересуют грамматики, то есть пара DSL-ей для их описания в этом формате:

https://github.com/nin-jin/tree.d/wiki/grammar.tree - тут в качестве примера можете увидеть грамматику самого tree.

https://github.com/nin-jin/tree.d/wiki/schema.tree - а тут схема языка описания схем.

Попробуйте в JSON без костылей продублировать ключ объекта, написать комментарий, указать предикат отличный от «равно», или добавить список тегов к строке. Всё это вынуждает изобретать свои микроформаты поверх базового.

Да, только это не экранирование, а список чанков, где в качестве открывающей кавычки для чанка используется бэкслеш, а закрывающей - перевод строки. Для получения бинарника достаточно сджойнить строки, используя перевод строки как разделитель.

Он является бинарным, но

сравнивается не с msgpack и CBOR, а с XML, YAML и JSON? Спасибо, до свидания.

У TN есть фундаментальная проблема - он парсит сырые данные. Это значит, что вместо строки на 200 байт, из него выйдет дерево на 40 узлов по 5 байт в среднем, единственное предназначение которых - быть потом сериализованными в строку на 100 байт. Это всё крайне не эффективно и дорого по памяти. В Tree такой проблемы нет благодаря разделению на структурные узлы и узлы данных.

В Tree, наоборот, формат отделён от языков. Так же как в XML. Один раз написал парсер/сериализатор формата, а далее просто бегаешь по AST, обрабатывая языки на его базе как хочешь, без возни с грамматиками.

Однажды, в студённую зимнюю пору

Не видите здесь ошибку? А она есть!

Это который в Питоне?

да

Я не про это а про универсальность. Еще раз, я пытался сделать такую универсальную (и даже более универсальную) шню, и мне самому оказалось с ней работать неудобно.

Отделено оно от ЯП или нет это детали реализации, а я про идеологию.

Кроме того микст из бинарных и текстовых данных это как правило ужасно (такой опыт у меня тоже был). Хотя бы потому, что открыв такое файло в редакторе (он же текстовый местами) можно превратить его в тыкву. Да и разбиение по переносам строки такое себе… Бинарный блоб пишется как длина фрагмента + фрагмент, не надо вводить никаких терминальных символов

Если хочется скорости однозначно надо брать чисто бинарный формат, он легко делается на коленке для всех актуальных контейнеров STL. Если хочется удобства и читабельности для конфигов, то надо брать чисто текстовый формат. А скрещивать ужа с ежом…

\ то зачем? Да и как то давно стандартом стал коммент через #.

Понятно, благодарю за ответ.

Тем не менее, лучше писать, что в 2 раза быстрее, нежели std.json, т.к. на данный момент формулировка может, к примеру, быть отнесена к какому-нибудь высокоскоростному jsoniter

В статье есть пояснение, почему парсер Tree концептуально быстрее JSON. То есть условный treeniter был бы ещё более высокоскоростным. Можете реализовать такой и прославиться.

Из того, что у вас что-то не получилось, не следует, что это невозможно. Многие уже пользуются Tree и получают удовольствие от отсутствия визуального шума и разумных ограничений, синтаксически не дающих наговнокодить. Tree - не серерянная пуля, а разумный компромисс. Это самый наглядный и гибкий среди бинарных форматов, и при этом самый компактный и шустрый среди текстовых.

А какой браузер?

Google Chrome Версия 107.0.5304.107 (Официальная сборка), (64 бит)

Я не говорю что это невозможно - я говорю что ИМНО такой подход имеет существенную родовую травму.

Многие уже пользуются Tree и получают удовольствие…

Вообще не аргумент вот ни разу. Многие много чего творят (скажем удовольствие от наркоты получают) - айда все ширятся?;-)

Это самый наглядный и гибкий среди бинарных форматов, и при этом самый компактный и шустрый среди текстовых.

Это очень сильное, и скорее всего неверное утверждение. Так говорить не надо (это не агрессия а добрый совет):

Вы не рассматривали ВСЕ текстовые и бинарные форматы, Вы взяли четыре. Кроме того понятия наглядности и гибкости зависит от человека и задачи. Мне скажем надо сериализовать данные с кольцевыми ссылками, tree из коробки этого делать не умеет. Комментарии через ; \ и переносы строк для бинарных данных для меня абсолютно ненаглядны. И далее по списку.

Нет, я понемаю, что по чужим ссылкам ходить не принято, но свои-то собственные ссылки надо хоть раз открыть? %)
Про краденый велосипед шучу, конечно,

Ходил и «не узрел кражи».

Без обид, но я не понял нафиг оно нужно. Как свой фонфиг под себя ок, почему бы и нет как новый стандарт хз даже, я вот себе свой придумал и транслирую его в lua выглядит так

!key {42}
!key.subkey{"42"}
!key
{
  !subkey{42.42}
  !message.one{'oneline str'}
  !message.twoo{" multi
  line
  str"}
  !arrays {
    !str{"a","b":"c"|""} -- три вида разделителей
    !num{1,2,3,4,5,6}
    !flt{-0.1,+0.2,1}
    !hexbin{0xff,0b111}
  }
}

Всё везде явно начинается и заканчивается типы только одного вида, либо значение в подключах либо ключи, все ключи начинаются на ! явно. Легко конвертируется в json/lua/xml портянкой в три строчки, типы примитивные, сложные просто строкой, пусть программа разбирает всякие даты и IP и прочее. Это максимально топорный, но наглядный,явный и гибкий формат который я для себя смог придумать. Имя ему effconf или sec. Я придумал я молодец :D

Это из разряда когда вконтактовские макаки вместо UTF-8 используют однобайтовую Windows-1251. Там экономия покруче твоей - в джва раза

А вы где территориально? У нас сервер в России, может быть не ото всюду доступен.

Оно имело бы смысл для какого-то говнораста под соусом самого безопасного формата данных. Если сравнивать с попсовыми языками, то у них у всех есть свой формат сериализации (PHP - serialize, Python - pickle, JS/Node.js - JSON (ага объектная нотация яваскрипт))

А вы где территориально? У нас сервер в России, может быть не ото всюду доступен.

Приблизительно понял как устроен бинарный формат, хотя конечно
желательно увидеть именно спецификацию, а не словесное описание.

Я в такие глуби не вдаваюсь. =) Вон большинство конфигов в системе просто blabla lala tutu tata строкой и парсятся обычным sscanf и всё нормально 99% случаев. nginx вон тоже взял под себя сделал фонфигурацию и норм всем никто не требует ничего. И так везде, это всякие ТОМЛЫ себя пиарят ини на стероидах, мы везде мы всё, мы вся. А нафига? Берушь что удобнее/эффективнее и всё, не нравится сам придумываешь один хрен сереализовать дополнительно на уровне приложения придётся всё. Ладно. Пускай химичит, химичить весело, почему нет.

Самому велосипедить с нуля много мороки. Вот, гляньте доклад, где рассказываться, как за считанные минуты сделать свой DSL, который транслируется в программный код с сорсмапами, точными координатами ошибок, подсветкой синтаксиса, авторефакторингами и тд.

Ух там целый час, попозже под чай может погляжу.

И так везде, это всякие ТОМЛЫ

Это go-шный, а yaml стал популярен благодаря ruby on rails. В XML все пихают сейчас только джависты…

А нафига? Берушь что удобнее/эффективнее и всё

Встроенное, что поддерживается стандартной библиотекой. В вебне считай один формат - JSON как раз по этой причине (встроенная поддержка клиентом (бр[оа]узером))

Ну да изкоробочность это важно. Только потом оно вытекает уже из коробки и заливает всё вокруг ибо «процессы уже налажены»