LINUX.ORG.RU

dhall-lang v9.0.0

 


0

1

Dhall – это программируемый язык конфигурации, который можно описать как: JSON + функции + типы + импорт.

Изменения:

  • Больше не поддерживается старый литеральный синтаксис Optional.
  • Запрет на суррогатные пары и не-символы.
  • Добавлено ключевое слово toMap для создания однородных ассоциативных списков из записей.
  • Бета-нормализация: улучшена сортировка полей записей.

Что нового:

  • Реализован импорт путей как местоположения – Location.
  • Разрешены все RFC3986-совместимые URL.
  • Появилась возможность добавления обобщенных комментариев к пустым спискам.
  • Добавлен тип Map и служебные функции в Prelude.
  • Возможность использования мультихеша для кэширования имен файлов.
  • Добавлена поддержка скрытых escape-последовательностей.
  • В Prelude добавлено стандартное представление для слабо типизированных значений JSON.
  • Добавлена возможность использования Prelude/Map для импорта заголовков.
  • Добавлен пакет Prelude/XML.

>>> Подробности

anonymous

Проверено: jollheef ()
Последнее исправление: shell-script (всего исправлений: 3)

Ответ на: комментарий от bread

поредактировать XML текстовым редактором. Типа Nano

Спецолимпиада?

Это лучшее объяснение, почему XML — не текстовый формат.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

нуу.. я ничего не решал.. я как раз выступаю за то, чтобы убрать этот заопарк и развивать текущий api... я помогал ребатам с их фетишем вокруг json схем... а потом забил и ушёл в запой...

вообще это дикость.. у чуваков бинари с сериализацией в xml (и если есть желание - в любой другой формат)... а они ведутся на гопников с json-ом.. невероятно. да?

графкуэль там чего-то какой-то высер сделал... но опять же.. где бинари.. просто графкуэль без возможности бинари - это извините.. и почему оно ориентировано на json?

кто-то там явно что-то не то хавает

none
()
Ответ на: комментарий от none

я помогал ребатам с их фетишем вокруг … схем

Не понимаю смысла своих специализированных схем, без разницы для xml, json и тп. О твоих схемах мало кто (точнее, никто) не знает и твой xml и json будет также непонятен как бинарный формат. Как описание формата - ни xml- ни json- схема неудобна для изучения. Зачем?

Лучше решали бы основную задача - упрощение api. Придумывали бы человекочитаемый DSL для описания данных. Вместо этого занимаются наложением толстых слоев модного и ненужного, и потом, чтобы понять что имелось в виду, приходится обратно соскребать это всё.

anonymous
()
Ответ на: комментарий от anonymous

Нет никакого срача. Все же (кроме макак) понимают, что это сорта того самого, только xml более продуман и внезапно удобен.

bread
()
Ответ на: комментарий от anonymous

Человекочитаемы дсл))) Посмеялся. Я согласен с основной частью. Но на счёт ДСЛ - типа очередной велосипед изобрести? ))

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

none
()
Ответ на: комментарий от bread

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

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Срач XML vs JSON в 2019 году,

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

Deleted
()
Ответ на: комментарий от none

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

Жду теорию множеств на русском языке. Давай, теорему Ферма докажешь на великом и могучем.

Но на счёт ДСЛ - типа очередной велосипед изобрести?

API - это практически DSL. Раз не можешь придумать простой dsl, так и скажи, что не можешь упростить api.

А замазать толстым слоем XML со схемами - это не упрощение.

anonymous
()
Ответ на: комментарий от anonymous

Какой ещё толстый слой? XML схема - хочешь пользуй. Хочешь не пользуйтесь - пиши сам вручную вместо того, генерить клиента и писать свою бизнес логику.

Не понимаю каким образом xml схема может ухудшить api. Если руки из жопы , то и dsl тут не поможет.

Иди доказывай теорему ферма на питоне. Бугага. Храбрец нашёлся, тоже мне

none
()
Ответ на: комментарий от Nill

Дело не в бинарности, а прямоте рук.

С действительно прямыми руками можно и ELF текстовым редактором править.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

Nill
()
Ответ на: комментарий от Deleted

Depends. Для скриптов или личных проектов — обычно YAML. Для кода, который пишу на работе — HOCON (корпоративный стандарт).

Miguel ★★★★★
()
Ответ на: комментарий от ugoday

Не понимаю каким образом xml схема может ухудшить api.

Жабист, который уже плотно сидит на всем этом расжиревшем рантайме с навязанными фреймворками, ничего сложного в этом не увидит. Он вскормлен сложностью. Подумаешь, формула количества сочетаний содержит факториал (экспоненцальный рост) от количетва элементов. Одной сущностью больше, одной сущностью меньше.

anonymous
()
Ответ на: комментарий от Miguel

HOCON

Еще один нескучный json.

корпоративный стандарт

Фейспалм. И эти люди запрещают нам ковыряться в xml.

anonymous
()

Анон, как ты умудрился самую главную фичу Dhall - вычислимость за конечное время - даже словом не упомянуть? Что за безобразие вместо новости?

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Хотел он по сути guaranteed-to-terminate typesafe nix (и собственно примерно его он и получил). КМК, было бы интереснее добавить в nix нормальную типизацию и возможность помечать отдельные функции как total (с проверкой на уровне языка). Было бы тьюринг-полным где надо и безопасным, где и так сойдет.

balsoft ★★
()
Ответ на: комментарий от balsoft

было бы интереснее добавить в nix нормальную типизацию

ниче ты кэп

и возможность помечать отдельные функции как total

в виде эвала куска на Dhall сойдет? =)

t184256 ★★★★★
()
Ответ на: комментарий от none

Во-первых, ты сравнил неправильно. Вот так правильно:

<books>
  <book title="so many special symbols" description="omg, i forgot quotes for description key. that sux" />
</books>
{
  "books": [
    {
      "title": "so many special symbols",
      "description": "omg, i forgot quotes for description key. that sux"
    }
  ]
}

Во-вторых, давай посмотрим на более реальный пример:

<connections>
  <connection alias="dpc_conn1" db="some_database">
    <mysql user="MYSQL_DPC_USER" pass="MYSQL_DPC_PASS" host="MYSQL_DPC_HOST" />
  </connection>
  <connection alias="dpc_conn2" db="another_database">
    <mysql user="MYSQL_DPC_USER" pass="MYSQL_DPC_PASS" host="MYSQL_DPC_HOST" />
  </connection>
  <connection alias="cluster_conn1" db="some_database">
    <mysql user="MYSQL_CLUSTER_USER" pass="MYSQL_CLUSTER_PASS" host="MYSQL_CLUSTER_HOST" />
  </connection>
</connections>
{
  "connections": [
    {
      "alias": "dpc_conn1",
      "db": "some_database",
      "mysql": {
        "user": "MYSQL_DPC_USER",
        "pass": "MYSQL_DPC_PASS",
        "host": "MYSQL_DPC_HOST"
      }
    }, {
      "alias": "dpc_conn2",
      "db": "another_database",
      "mysql": {
        "user": "MYSQL_DPC_USER",
        "pass": "MYSQL_DPC_PASS",
        "host": "MYSQL_DPC_HOST"
      }
    }, {
      "alias": "cluster_conn1",
      "db": "some_database",
      "mysql": {
        "user": "MYSQL_CLUSTER_USER",
        "pass": "MYSQL_CLUSTER_PASS",
        "host": "MYSQL_CLUSTER_HOST"
      }
    }
  ]
}

И тут я даже немного изменил своё мнение о XML. Получилось ведь короче.

Но как только я попробовал прочитать структуру, я понял, что это дерьмо. Сперва мне нужно прочитать атрибуты, затем внутренние теги, потом смерджить это в голове, потом понять что тоже самое нужно сделать с вложенными объектами и выкинуть XML на помойку.

В то время как в языке программирования я сразу вижу структуру:

struct Connection {
  struct strbuf Alias;
  struct strbuf Db;
  struct{
    struct strbuf User;
    struct strbuf Pass;
    struct strbuf Host;
  } MySQL;
};

Попробуем отказаться от атрибутов и написать всё в тегах:

<connections>
  <connection>
    <alias>dpc_conn1</alias>
    <db>some_database</db>
    <mysql>
      <user>MYSQL_DPC_USER</user>
      <pass>MYSQL_DPC_PASS</pass>
      <host>MYSQL_DPC_HOST</host>
    </mysql>
  </connection>
  <connection>
    <alias>dpc_conn2</alias>
    <db>another_database</db>
    <mysql>
      <user>MYSQL_DPC_USER</user>
      <pass>MYSQL_DPC_PASS</pass>
      <host>MYSQL_DPC_HOST</host>
    </mysql>
  </connection>
  <connection>
    <alias>cluster_conn1</alias>
    <db>some_database</db>
    <mysql>
      <user>MYSQL_CLUSTER_USER</user>
      <pass>MYSQL_CLUSTER_PASS</pass>
      <host>MYSQL_CLUSTER_HOST</host>
    </mysql>
  </connection>
</connections>

Уже лучше! Нет красоты атрибутов, зато есть лёгкость видимости структуры. Тем не менее, по сравнению с JSON это дерьмо.

elonmusk
()
Ответ на: комментарий от none

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

HashTable со строковым ключом?

elonmusk
()
Ответ на: комментарий от elonmusk

Попробуем отказаться от атрибутов и написать всё в тегах:

Ну вот, так потихоньку и научишься XML.

по сравнению с JSON это дерьмо

Смотри внимательнее, оно же эквивалентно. Только в xml теги, в json пунктуация. Если данные будут чуть сложнее пары слов, то уже json извините соснет. Не говоря о том, что там нет многих возможностей xml, тех же атрибутов (которые правда надо уметь применять).

bread
()
Ответ на: комментарий от bread

в 2000 свалил с java только из-за того, что понял, куда все катится. без ide даже сраный hello world не слепить и никто в проекте уже ничего не понимает, потому, что концов никогда не найти. начинаешь копать и бац - xml и уже никакой жизни не хватит докопаться до истины. примерно как в https://www.youtube.com/watch?v=-X0TM7Te-AY

а так, да - xml был задуман для хорошего, но как-то так вышло, что ничего хорошего из этого не вышло.

dummy ★★
()
Последнее исправление: dummy (всего исправлений: 1)
Ответ на: комментарий от none

Русский язык

Понятный

Под любой домен подходит

ахаха, прекрати!

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.