Comments 69
Эту чушь уже где-то постили раньше… А, да, вот, нашел https://habr.com/ru/post/248147/
Похоже, что вы не сделали выводов из сильно отрицательного рейтинга прошлого аккаунта, не так ли?
Потому что проблема этого автора — вовсе не в "инакомыслии".
Как и Вернадскому, мне кажется разумным утверждение что идеи приходят в наш мир разом в множество голов способных улавливать их еле-уловимое звучание. В 2014 меня так же, как и многих терзали мысли о годном реактивном контейнере данных. Всякие кефиры и RX до сих пор выглядят как кнопочные телефоны. Атом автора статьи ещё тогда оказался точной реализацей того как я слышал звучание этой идеи. Но даже такую простую частичку не было возможности подтянуть в свой проект, не понятно как. А всё остальное до сих пор остаётся ещё более не понятным и значит не нужным.
Орки некогда были прекраснейшими существами эльфийского рода, пока создатель кольца всевластья не пленил их модифицировав код, сменил скин, хакнул волю. В древней греции эйдосами называли прекрасные идеи, в нашем мире они измучаны, модифицированы и известны как эгрегоры. Так как ты ворвался в битву идей, мне кажется важно это понимать, хотяб кто с кем сражается. )
Вселенная $mol имеет в себе массу полезных и настоящих идей, за которые сражаюсь в текущем мире, но может оказаться
Как мне кажется сравнивать похоже полноценный DSL от $mol с JSON не очень корректно, как и с YAML. Принижая других, лучше не стать. Почему нет дружбы с другими форматами/библиотеками, как и самой вселенной $mol в npm репозитриях?
Все остальные должны умереть?
Всё те же самые ошибки, которые ещё в прошлой статье были...
Хранение сырых бинарных данных в Data Node противоречит пункту об удобочитаемости и отсутствии экранирования.
Как XML, так и JSON на самом деле поддерживают поточную обработку. Наличие поточной обработки — это вообще фича парсера, а не формата. То же самое с позициями.
В AST откуда-то взялся type, хотя ранее утверждалось, что никаких типов нод в Tree нету.
В результате вагончик не едет ни туда, ни сюда.
Приведёте пример послойного отображения?
The *.pyi files are used by PyCharm and other development tools to provide more information, such as PEP 484 type hints, than it is able to glean from introspection of extension types and methods. They are not intended to be imported, executed or used for any other purpose other than providing info to the tools. If you don't use use a tool that makes use of .pyi files then you can safely ignore this file.stackoverflow.com/a/55055248
See: www.python.org/dev/peps/pep-0484 www.jetbrains.com/help/pycharm/2016.1/type-hinting-in-pycharm.html
Заголовочные файлы и файлы деклараций (
*.d.ts) также можно рассматривать как отдельные слои.А какой смысл прятать информацию о типах?
2. Делать частичные дифы, где будет представлена только часть информации (как уже сейчас многие интерфейсы предлагают игнорировать изменения в пробельных символах).
3. Больше кода вмещается на один экран (или на один столбик экрана) — легче перемещаться по коду.
И пр. и пр.
С тем же успехом можно и параметры функций скрывать и инициализацию переменных вырезать.
Формат Tree понравился.
Попробую применить на практике.
Тут подсказывают, что есть похожий проект — Tree Notation. Он выглядит взрослее. Хотя сам этот формат на мой взгляд не очень, так как не разделяет структуру и данные.
Да, лексически это не более, чем список строк, состоящих из отступа, списка имён и сырых данных. Для синтаксического анализа нужна уже не хитрая логика с подсчётом числа отступов. Это если и можно отразить в BNF, то сложно, и имеет мало смысла.
Не обязательно выражать БНФ абсолютно точно, но это всё равно будет лучше, чем выражать его так ложно. Можно и расширить БНФ специальный понятием, позволяющим выразить всё как надо.
Вы всё же путаете лексический и синтаксический анализ. Результатом первого является именно что плоский поток токенов языка. Делается это для упрощения синтаксического анализа.
У Меня он всё же задаёт именно лексический уровень.
напишем полную формальную грамматикуВы или придумали свои определения для известных терминов, либо меняете показания на лету
Вы или придумали свои определения для известных терминов, либо меняете показания на лету
И вы всё ещё спрашиваете за что ему карму сливали? Он ведь каждый раз так делает...
И таким образом вы можете легко рефакторить любые языки, основанные на tree формате, без поиска для каждого языка отдельного парсера и разбирательства с тем, как у него происходит работа с AST.Есть программа на неком языке, в которой указанный в примере auth не только объявлен, но и упоминается в некотором контексте, а, возможно, что он ещё и не уникален по имени, но уникален по контексту. Каким образом представленный механизм позволит легко это изменить?
На языке jack.tree такая трансформация может выглядеть так:
hack google
hack auth credentials from
clone fromТо есть матчимся на контекст (google), клонируем его как есть, но добавляем вложенный хак, который уже матчится на auth и заменяет его на credentials. На JS всё то же самое, только кода чуть больше:
return config.list(
config.hack({
google: ( google, belt )=> [
google.clone(
google.hack({
auth: ( auth, belt )=> [
auth.struct( 'credentials',
auth.hack( belt )
),
],
}),
),
],
}),
)type Google = { auth string }
a: Google
a.auth = "Bam"Я так понимаю вы про семантический рефакторинг? Он, очевидно, на уровне AST не возможен.
И таким образом вы можете легко рефакторить любые языки, основанные на tree формате, без поиска для каждого языка отдельного парсераесли отдельный парсер такую возможность даёт?
И отдельный парсер такой возможности не даёт. Это даёт тайпчекер и то лишь для языков со статической типизацией.
Этим занимается семантический анализатор. Впрочем, терминологические споры мне не интересны. Можете хоть компилировать на этапе парсинга — суть процесса от этого не поменяется.
Какой смысл в Вашем рефакторинге, который не решает задач рефакторинга? Как в анекдоте — зато дёшево ж?
Вы говорите, что терминологический спор Вас не интересует, но, по факту, этот диалог в значительной степени вокруг этого и строится. Типичный парсер для многих языков требует для своей работы анализа объявлений и нет никакого смысла выкидывать эту часть для того, чтобы сделать это потом в отдельном семантическом анализаторе.
В такой форме запрос распарсить — плёвое дело, в отличие от настоящего SQL.А если ненастоящий, а только то подмножество, что достаточно для разбора таких запросов? Не подменяете ли Вы понятия?
Такое подмножество уменьшит и выразительную мощность. В sql.tree выразительная мощность может быть даже больше.
Tree никак не решает проблему проверки корректности составленной конструкции и следовательно разбор выражения делать всё равно придётся и его нельзя сводить к «дерево уже построено»
Потому что "подмножество", а не "надмножество", как в случае с sql.tree.
Такую проверку для AST написать существенно проще, чем сделать то же самое для sql как текста.
Небольшой апдейт по теме
tree.hyoo.ru — песочница, где можно погонять различные трансформации. Вот несколько примеров:
- view.tree ⇒ view.ts — трансляция описания компонент в код на TypeScript.
- view.tree ⇒ locale.json — экспорт референсных текстов для локализации в виде JSON из описания компонент.
- view.tree ⇒ view.dts — экспорт TypeScript типов со встроенными сорсмапами из описания компонент.
- JSON ⇒ json.tree — трансляция JSON в json.tree.
- xml.tree ⇒ XML — трансляция xml.tree в XML
- js.tree ⇒ JS — трансляция JavaScript AST в собственно JavaScript.
- wasm.tree ⇒ WASM — компиляция WASM AST в WASM бинарник и проверка его корректности. Эта штука пока ещё сильно сырая: поддерживаются лишь 3 типа секций, нельзя тут же в песочнице его запустить. Но как будет время докурю спецификацию.
- jack.tree ⇒ JS eval — трансляция мета-языка с генерацией JavaScript со встроенными сорсмапами и тут же его исполнение.
- MarkedText ⇒ JS — трансляция MarkedText в код JavaScript со встроенными сорсмапами, который генерирует DOM дерево, используя DOM API.
- grammar.tree check — проверка корректности grammar.tree описания синтаксиса налету.
- span.tree imprint/reuse — зашивание исходников и маппинга в span.tree дерево, его промежуточная сериализация в строку, с последующим восстановлением исходного дерева без потери маппинга.
- automate.tree (JS) — пример написания собственной трансформации на JavaScript, преобразующей простой скрипт автоматизации в код на JavaScript со встроенными сорсмапами.
- automate.tree (jack) — то же самое, но используя язык jack.tree.
Фух, надеюсь нигде со ссылками не наврал. mayorovp поправит, если что.
Конечно, можно и в обратную сторону.
Попробовал, но он ломается даже в зависимости от переводов строк. Толком ничего не могу получить. В лучшем случае выдаёт XML же, но испорченный
И «undexpected» — это ошибка в выводе ошибок :)
Tree — единый AST чтобы править всеми