Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
Уникальная нотация языка UNO создаёт ему огромный потенциал, позволяющий в перспективе заменить большинство нынешних языков разметки данных
Ну классика же
Это настолько предсказуемо и уже давно не смешно. Может быть нам всем следует отказаться от попыток что-то улучшить или вообще вернуться в докаменный век, стать животными не умеющими использовать орудия труда?
Улучшать конечно следует. Но в статьях довольно безаппеляционно утверждается что формат на голову лучше всех существующих вместе взятых - 5 звезд по всем пунктам, хотя из примеров это вообще ни разу не очевидно, можно начать хоть с читаемости - даже на маленьких примерах нужно запоминать кучу знаков препинания и что они делают, на большом файле получится египетское письмо и читаемость развалится полностью. Банально из за сложности формата, т.к. слишком много функций заложено.
Процентов 5 токенов при работе с ллмками наверное сэкономит, в том направлении мб больше перспектив.
Прошу прощения за безапеляционность. Пришлось намеренно ввести элемент провокационности исключительно для привлечения внимания, т.к. первая статья https://habr.com/ru/articles/1075348/ прошла незаметно. Что касается сложности обусловленной мощностью функционала, это решено путём разделения на продвинутую и основную спецификацию UNO Core, в которой нет никаких модификаторов, импортов и прочего.
Т.е. имеем уже два не полностью совместимых между собой формата, и, любопытства ради глянул сайт - на подходе еще и третий
При этом это все продумано довольно плохо - к примеру, числа у вас в простой версии ограничены 64-битным с плавающей точкой, и 64-битное целое придется выражать через строку, то есть по типизации вы уже проигрываете даже json которому поставили два балла. А в усложненной версии перед каждым придется лепить какие то модификаторы
И все это, не совсем понятно какую проблему должно решать
Не так. Если делитель выражения двоеточие, то это строка, если знак равно, то это число (f64). key= 12345
Если вам, как составителю данных важно указать иной формат, то вы можете двигаться двумя путями (как вам покажется удобнее в конкретной ситуации):
либо указать требуемый тип данных непосредственно в строке key= int:12345
либо в проверочном шаблоне добавить проверку $ type: int
Всё элементарно. А если вы имеете в виду неявное определение типа числа по наличию точки key= 12345.0, то это тупиковый путь. Составителю придётся ставить эти точки и нули (а UNO Core предназначается и для ручного оформления данных) и обязательно забудет это сделать. А оставить это для угадывания нельзя: допустим мы передаём список товаров с ценами и где-то будет стоять точка, а где-то нет -- возникнет коллизия. Плюсом отказа от угадывания является и ускорение обработки данных парсером.
Если делитель выражения двоеточие, то это строка, если знак равно, то это число
Это вообще дичь какая то если честно
допустим мы передаём список товаров с ценами и где-то будет стоять точка, а где-то нет -- возникнет коллизия
Где она возникнет? В коде приложения работающего с данными коллизии не возникнет - там и так известно какой тип данных ожидается, и если цена, то десериализуется в число с плавающей точкой, и парсер оба варианта переваривает в него. А человеку смотрящему в файл вообще пофиг, он тем более и так и так понимает. В том же json ни у кого никаких проблем с коллизиями нет. А у вас получается в формат затащены костыли для обхода проблем в каком то одном конкретном парсере.
Дуализм делителя это великая находка, позволяющая красиво решить поставленные перед языком задачи.
Если у вас настроение только выискивать негатив, а не попытаться понять иной, непривычный для вас подход, то не мучайте себя.
Если у передающей и принимающей сторон есть соглашение (описание данных), то, естественно, коллизий не возникнет ни в XML ни в JSON, ни в YAML, ни в других языках разметки. Но много ли вы встречали, например, действительно рабочих описаний XSD? Обычно всё решается полуформально и догадками. UNO же позволяет многое передавать самоописанием без соглашений (в статье ещё не все аспекты заявлены).
Дуализм делителя это великая находка, позволяющая красиво решить поставленные перед языком задачи.
С красотой и величием, а, главное логикой, решения, заталкивающего часть типизации в (!) разделитель, а всю остальную в префиксы и дублирование этого всего потенциально конфликтующей отдельной схемой как раз таки все понятно.
А задачи то, учитывая такой способ обфускации, перед языком какие поставлены?
А вот так это выглядит на ron(Rusty Object Notation), и как по мне выглядит понятнее:
(
книга: (
rating: 4.9,
артикул: "LOTR-SILM-01",
название: "Сильмариллион",
авторы: [
"Дж. Р. Р. Толкин",
"Кристофер Толкин",
],
основной_жанр: "Эпическое фэнтези",
аннотация: r#"История Первой Эпохи Средиземья, создания Сильмарилей и падения Моргота.
Древняя хроника, определившая лицо современной мифологии."#,
коммерция: (
цена: Rub(1200),
тираж: 50000u32,
вес: Grams(650),
),
),
)
Вроде как Rub(1200) и Grams(650)невалидно. В RON это валидно, только если это именованные Tuple Struct или Enum-варианты. Если это просто текст, нужны кавычки. Да и прочее вызывает сомнение. Скорее всего код будет выглядеть так:
{
"книга": {
"rating": 4.9,
"артикул": "LOTR-SILM-01",
"название": "Сильмариллион",
"авторы": [
"Дж. Р. Р. Толкин",
"Кристофер Толкин",
],
"основной жанр": "Эпическое фэнтези",
// Сырые строки (Raw strings) в RON поддерживаются идеально
"аннотация": r#"История Первой Эпохи Средиземья, создания Сильмарилей и падения Моргота.
Древняя хроника, определившая лицо современной мифологии."#,
// Коммерческий блок как вложенная мапа
"коммерция": {
"цена": 1200,
"валюта": "rub",
"тираж": 50000, // суффикс u32 убираем, RON его не поймет
"вес": 650,
"единица_измерения": "g",
},
},
}
Но я не специалист, настаивать не буду. К тому же и первый вариант мне нравится меньше, чем УНО.
Ну так и цена= 1200 rub тоже не валидна, если читающая сторона не сможет распознать/обработать тип данных. А если читающая сторона знает про этот тип данных то она знает и про Rub(1200).
RON понимает суфиксы u32 и другие rust-суфиксы начиная с версии 0.9 “Fix issue #241 and allow parsing numbers with explicit type suffixes, e.g. 1u8 or -1f32 (#481)”.
Вообще в ваших примерах спецификации нехватает того как и во что это должно читаться. Если вы утверждаете что у вас типизация на 5 звёзд, а не просто числа/строки, то этот момент как мне кажется самый ключевой. Потому, что валидность данных будет определять не сам формат/спецификация, а читающая сторона. Не хватает описание поведения читающей стороны, когда приходят данные несоответствующие(или неоднозначны) её модели данных.
Ну да, отправитель и принимающая сторона могут договориться о каких-то своих правилах и понимать друг-друга в частном случае. Однако язык обмена данными подразумевает возможность нормальной интерпретации данных и неподготовленной стороной. По идее они могут взять стандартный парсер, который проверит синтаксис и при отсутствии ошибок переведет всё в абстрактное дерево, а затем уже можно конвертировать в привычный джейсон или что иное, но эффективнее как раз оперировать данными напрямую из абстрактного представления.
В данном примере цена= 1200 rub абсолютна валидна в UNO, такое представление называется спаренное значение, состоящее из величины и единицы её измеряющей.
каждый формат имеет свое предназначение:
.env - мало переменных
.ini - много переменных, разделённых по группам
.toml - много переменных, разделённых по группам, умеет хранить сложные структуры
.json - одна сложная структура, с вложенными структурами
.xml - одна сложная структура, с вложенными структурами, может иметь описание полей
Я использую .env,
раньше использовал .ini когда было много переменных(значений)
.toml наверное лучше, но у меня нет сложных структур, и нет в нём необходимости
Не надо делать единый формат, для каждого предназначения должен быть свой формат.
А вот мне не хотелось бы вникать в множество форматов. Мне кажется можно оставить CSV(TSV), XML, чистый JSON, UNO, возможно ещё какие-то узкоспециализированные типа Apache Parque -- в нём я не разбирался ещё и бинарные.
UNO можно без проблем использовать как замену экстремально минималистичному ENV и будет даже короче, можно не проставлять кавычки для текстовых значений.
не хватает формата tree Дмитрия Карловского (спецификация). Он сделан ровно по тому же принципу «минимум разметки», но с ещё более простой грамматикой: узел это слово, вложенность через таб, а любая сырая строка начинается с \ и никогда не экранируется.
пример с книгой:
книга
рейтинг 4.9
артикул \LOTR-SILM-01
название \Сильмариллион
авторы
\Дж. Р. Р. Толкин
\Кристофер Толкин
основной_жанр \Эпическое фэнтези
аннотация
\История Первой Эпохи Средиземья, создания Сильмарилей и падения Моргота.
\Древняя хроника, определившая лицо современной мифологии.
- Коммерческая информация
цена 1200 \rub
тираж 50000
вес 650 \g
Что тут:
Многострочный текст — просто несколько строк с \, никаких терминаторов и правил про отступы внутри блока.
Разделение «структура / данные» на уровне синтаксиса: всё без \ — узлы дерева, всё после \ — байты как есть. Это тот же дуализм, что у вас между : и =, только через один символ.
Грамматика умещается в несколько строк, парсер пишется за вечер на любом языке — и он тоже однопроходный.
Комментарий — обычный узел -, то есть он остаётся в AST и его можно обрабатывать, а не выбрасывать.
Метаданных, типов и валидации как отдельных механизмов в tree нет, но есть в подмножествах языков tree
Например view.tree является типизированным и используется для декларативного описания веб компонент
рейтинг 4.9
артикул \LOTR-SILM-01
название \Сильмариллион
автор \Дж. Р. Р. Толкин
автор \Кристофер Толкин
основной_жанр \Эпическое фэнтези
аннотация \
\История Первой Эпохи Средиземья, создания Сильмарилей и падения Моргота.
\Древняя хроника, определившая лицо современной мифологии.
- \Коммерческая информация
цена 1200 \rub
тираж 50000
вес 650 \gЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Способен ли UNO заменить TOML, YAML, KDL, HCL, EDN и другие языки разметки данных?