Не очень понятно, как это возможно, потому что фичу для KPHP делал лично я, статью писал - тоже я, игру для демонстрации, опять же, вместе со мной делали.
У FFI в KPHP есть свои особенности. Например, есть типы ffi_cdata и ffi_scope, без которых код работать не будет. По ходу повествования я раскидал ещё парочку трюков, которые были необходимы, чтобы игра запускалась и на PHP, и на KPHP.
Там есть как разработчики самого KPHP, так и пользователи. Присоединяйтесь. :)
А ещё есть https://github.com/quasilyte/awesome-kphp, который может стать более полным с вашей помощью. Через FFI можно реализовать недостающий функционал, а чтобы о ваших библиотеках было проще узнать остальным пользователям - давайте добавлять все полезняшки в этот индекс.
Я на eg обращал ранее внимание, но к нему маловато документации и примеров. Выглядит как более простая утилита, чем gogrep, я так понимаю, там нет фильтров по атрибутам и не построить конвейеры. Использовать отдельный файл с before/after выглядит не так удобно для интерактивной команды (хотя расширение могло бы создавать такой файл самостоятельно).
Есть ещё малоизвестный (?) gofmt -r, сравнение с которым было в докладе автора gogrep.
Я не знаю, сделано для Go или нет, но в IDE известной компании есть SSR, который работает для нескольких ЯП.
В ruleguard есть возможность описывать quickfix на основе тех же gogrep шаблонов. Разница в том, что можно хранить правила в отдельном файле, что позволит на сохранении заменять всё, что хочется упрощать автоматически. Вот простой пример:
Надо обладать определенной смелостью, чтобы от лица компании публично критиковать слова другого человека.
Мне кажется, не обязательно приписывать любое высказывание сотрудника высказыванию от лица компании. Как минимум, этот пост не в блоге Яндекса.
Я не знаю, когда это было добавлено в статью, но сейчас там есть это:
Дисклаймер: написанное ниже является моим личным мнением, официальное мнение компании по данному вопросу мне неизвестно.
Ради мыслительного эксперимента, мы можем поставить себя на место другого. Если некто работает в компании X, ему или ей может быть не очень приятно, если любое высказывание (даже с дисклеймером) могут назвать высказыванием от лица X.
Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.
Первые встречи сообщества, помню, можно было делать гораздо проще, всё ощущалось непринуждённо. Я бы и дальше делал бы такие встречи с минимальными усилиями, но некоторые не согласны с такой позицией.
Если бы в статье не было практически прямых оскорблений и принижения чужой позиции, она была бы менее популярной на хабре?
Я могу согласиться с посылом статьи, так как я тоже за статическую типизацию, но нападения на других людей отталкивает от текста, отвлекает от мысли. Мне не нравится читать о "динамической типизации", но отвлекаться на описание чьей-то "башки" и приравнивание её к тупой.
В списке причин минуса к статье нет такого, который описывал бы агрессивность изложения, а ставить за "другое" не хочется. Есть "личная неприязнь к автору", но я же автора как человека не знаю, мне конкретно текст не нравится. :)
С введением причин для минусов к статье начинаешь пытаться искать корни проблемы.
Я не до конца понимаю, почему несколько людей отметили материал меткой "Низкий технический уровень материала". Если это более заметно со стороны, мне честно было бы интересно узнать, что подрывает техническую сторону статьи.
Эта статья по оценкам получилась провальной и демотивирует в том числе то, что я не знаю, как можно было бы сделать лучше.
Код в gist'е понятен (спасибо, что скинули его в дополнение к коду Вирта, иначе было бы сложнее). Мне субъективно больше нравятся парсеры Пратта тем, что там, на мой взгляд, лучше разделена логика парсинга.
Есть ещё возможность динамически определять грамматику и дополнять её программно: почти вся логика парсера сосредоточена в отображениях {токен => обработчик}. Не то, чтобы очень мне лично было полезно, но, выражаясь по-английски, it's fascinating. :)
P.S. — удалил из статьи абзац, который вы цитировали в первом комментарии. :)
В конце статьи я ссылаюсь на Pratt Parsers: Expression Parsing Made Easy . В целом, я старался в одно предложение выразить это:
You can do this with recursive descent, but it’s a chore. You have to write separate functions for each level of precedence (JavaScript has 17 of them, for example), manually handle associativity, and smear your grammar across a bunch of parsing code until it’s hard to see.
Зачем я это вообще пытался добавить? Изначально это планировалось переводом, а потом уже осталось как артефакт после множественных редактирований.
Алгоритм Пратта — тоже рекурсивный спуск, просто с определённым подходом (расширением?), чтобы более красиво обработать произвольные выражения.
Если без какой-то системы делать, парсер будет выглядеть как запутанный код.
Конкретных примеров под рукой нет, но почти все мои первые парсеры с рекурсивным спуском были ужасны. Я даже не уверен, что они правильно обрабатывали приоритеты операций, кажется, для этого я использовал Shunting-yard, который тоже мне не с первого дня дался. До ассоциативности я, возможно, в те дни даже не доходил. :)
Парсеры Пратта довольно аккуратно решают эту проблему.
Но опять же, возможно вы очень опытный специалист в области парсинга, тогда любой ваш парсер будет хорошо выглядеть. Но это не означает, что концепции рекурсивного спуска достаточно, чтобы написать всё элегантно.
Может, стоило написать, что создать хороший парсер выражений по одному лишь описанию рекурсивного спуска можно, но это требует или опыта, или дисциплины.
Аргументы в пользу использования генератора парсеров (имхо):
У вас уже есть грамматика на руках.
Вам важна производительность парсера.
Сложно написать парсер вручную.
Хотя стоит заметить, goyacc не генерирует слишком быстрый парсер, там будет очень много аллокаций. Но может его нужно просто правильно готовить.
То есть:
Да, можно.
Смотрите по ситуации.
Хотя бы разок написать парсер ручками точно полезно. :)
Потом это быстро надоест и вы будете уже более взвешенный выбор принимать, зная плюсы и минусы обоих подходов.
А ещё алгоритм Пратта — это не новый подход. :)
Но он вроде бы не очень популярен.
Так что я думаю польза для разработчиков может быть хотя бы из того, что можно подсмотреть в код и позаимствовать некоторые идеи.
Я постарался собрать список других проектов, которые так или иначе используют шаблоны для статического анализа. Можно туда так же добавить расширения ES Lint и подобные, но всё-таки там не AST-шаблоны, а своеобразный DSL из ключей-значений.
Также несколько раз делались разборы Open-Source проектов через NoVerify, после чего меинтейнерам отправлялись патчи с исправлениями багов. Тоже некоторая польза сообществу. :)
С моим опытом не согласуется, но минус за комментарий (не в карму) я поставил из-за того, что ваш комментарий довольно кусачий и некоторых может незаслуженно обидеть.
Решил дать вам знать. Возможно, кто-то еще поставил минус по той же причине.
Не очень понятно, как это возможно, потому что фичу для KPHP делал лично я, статью писал - тоже я, игру для демонстрации, опять же, вместе со мной делали.
У FFI в KPHP есть свои особенности. Например, есть типы ffi_cdata и ffi_scope, без которых код работать не будет. По ходу повествования я раскидал ещё парочку трюков, которые были необходимы, чтобы игра запускалась и на PHP, и на KPHP.
Напоминаю, что у KPHP есть чатик сообщества в телеграме: https://t.me/kphp_chat
Там есть как разработчики самого KPHP, так и пользователи.
Присоединяйтесь. :)
А ещё есть https://github.com/quasilyte/awesome-kphp, который может стать более полным с вашей помощью. Через FFI можно реализовать недостающий функционал, а чтобы о ваших библиотеках было проще узнать остальным пользователям - давайте добавлять все полезняшки в этот индекс.
Мы там даже обсуждаем всякие внутренности KPHP и помогаем тем, у кого возникают проблемы с использованием.
Так что welcome. :)
Я думаю, вы про https://plugins.jetbrains.com/plugin/9927-deep-assoc-completion ?
Из коробки PhpStorm, кажется, такое не поддерживает.
А кроме автодоплений для tuple и shape типов плагин умеет ещё и другие вещи.
FAQ.
Q: Что такое "движки"?
A:
s/движки/сервисы/(или "демоны") — сервис сообщений, сервис лайков, etc.Из статьи:
Q: А как происходит обращение к полям из KPHP?
A: По именам, но без динамических выражений.
Не особо.
Но если поискать в интернете, автоматическую векторизацию вроде как не хотят добавлять из-за потенциального замедления компиляции.
Новый calling convention уже давно обсуждается и там есть некоторые успехи в этом направлении. Тоже по Go трекеру можно найти.
mid-stack инлайнинг уже работает из коробки. Эвристики инлайнинга вроде тоже несколько раз подкручивали.
Сворачивание константных выражений тоже, скорее всего, улучшилось. Хотя чудес типа символического исполнения я бы не ждал.
Добавлю в статью и унесу под спойлер. :)
Я на
egобращал ранее внимание, но к нему маловато документации и примеров. Выглядит как более простая утилита, чемgogrep, я так понимаю, там нет фильтров по атрибутам и не построить конвейеры. Использовать отдельный файл с before/after выглядит не так удобно для интерактивной команды (хотя расширение могло бы создавать такой файл самостоятельно).Есть ещё малоизвестный (?)
gofmt -r, сравнение с которым было в докладе автора gogrep.Я не знаю, сделано для Go или нет, но в IDE известной компании есть SSR, который работает для нескольких ЯП.
В ruleguard есть возможность описывать quickfix на основе тех же
gogrepшаблонов. Разница в том, что можно хранить правила в отдельном файле, что позволит на сохранении заменять всё, что хочется упрощать автоматически. Вот простой пример:Находим вызовы
Fprintfс аргументовStdoutи заменяем наPrint*функции.Мне кажется, не обязательно приписывать любое высказывание сотрудника высказыванию от лица компании. Как минимум, этот пост не в блоге Яндекса.
Я не знаю, когда это было добавлено в статью, но сейчас там есть это:
Ради мыслительного эксперимента, мы можем поставить себя на место другого. Если некто работает в компании X, ему или ей может быть не очень приятно, если любое высказывание (даже с дисклеймером) могут назвать высказыванием от лица X.
Если кто-то использует VS Code для PHP, то теперь под него есть расширение для удобного использования phpgrep.
Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.
Первые встречи сообщества, помню, можно было делать гораздо проще, всё ощущалось непринуждённо. Я бы и дальше делал бы такие встречи с минимальными усилиями, но некоторые не согласны с такой позицией.
Если бы в статье не было практически прямых оскорблений и принижения чужой позиции, она была бы менее популярной на хабре?
Я могу согласиться с посылом статьи, так как я тоже за статическую типизацию, но нападения на других людей отталкивает от текста, отвлекает от мысли. Мне не нравится читать о "динамической типизации", но отвлекаться на описание чьей-то "башки" и приравнивание её к тупой.
В списке причин минуса к статье нет такого, который описывал бы агрессивность изложения, а ставить за "другое" не хочется. Есть "личная неприязнь к автору", но я же автора как человека не знаю, мне конкретно текст не нравится. :)
На afterparty планируем делать live выпуск GenericTalks.
Это если кому-то захочется переключиться с основной комнаты для обсуждений.
С введением причин для минусов к статье начинаешь пытаться искать корни проблемы.
Я не до конца понимаю, почему несколько людей отметили материал меткой "Низкий технический уровень материала". Если это более заметно со стороны, мне честно было бы интересно узнать, что подрывает техническую сторону статьи.
Эта статья по оценкам получилась провальной и демотивирует в том числе то, что я не знаю, как можно было бы сделать лучше.
Спасибо, весьма познавательно.
Код в gist'е понятен (спасибо, что скинули его в дополнение к коду Вирта, иначе было бы сложнее). Мне субъективно больше нравятся парсеры Пратта тем, что там, на мой взгляд, лучше разделена логика парсинга.
Есть ещё возможность динамически определять грамматику и дополнять её программно: почти вся логика парсера сосредоточена в отображениях
{токен => обработчик}. Не то, чтобы очень мне лично было полезно, но, выражаясь по-английски, it's fascinating. :)P.S. — удалил из статьи абзац, который вы цитировали в первом комментарии. :)
В конце статьи я ссылаюсь на Pratt Parsers: Expression Parsing Made Easy . В целом, я старался в одно предложение выразить это:
Зачем я это вообще пытался добавить? Изначально это планировалось переводом, а потом уже осталось как артефакт после множественных редактирований.
Алгоритм Пратта — тоже рекурсивный спуск, просто с определённым подходом (расширением?), чтобы более красиво обработать произвольные выражения.
Если без какой-то системы делать, парсер будет выглядеть как запутанный код.
Конкретных примеров под рукой нет, но почти все мои первые парсеры с рекурсивным спуском были ужасны. Я даже не уверен, что они правильно обрабатывали приоритеты операций, кажется, для этого я использовал Shunting-yard, который тоже мне не с первого дня дался. До ассоциативности я, возможно, в те дни даже не доходил. :)
Парсеры Пратта довольно аккуратно решают эту проблему.
Но опять же, возможно вы очень опытный специалист в области парсинга, тогда любой ваш парсер будет хорошо выглядеть. Но это не означает, что концепции рекурсивного спуска достаточно, чтобы написать всё элегантно.
Может, стоило написать, что создать хороший парсер выражений по одному лишь описанию рекурсивного спуска можно, но это требует или опыта, или дисциплины.
Есть как минимум 2 версии
goyacc. Та, на которую вы ссылаетесь и более новая: https://gitlab.com/cznic/goyacc.Реальное применение можно увидеть в проекте github.com/z7zmey/php-parser. В NoVerify как раз используется такой парсер, сгенерированный goyacc.
Аргументы в пользу использования генератора парсеров (имхо):
Хотя стоит заметить,
goyaccне генерирует слишком быстрый парсер, там будет очень много аллокаций. Но может его нужно просто правильно готовить.То есть:
Хотя бы разок написать парсер ручками точно полезно. :)
Потом это быстро надоест и вы будете уже более взвешенный выбор принимать, зная плюсы и минусы обоих подходов.
А ещё алгоритм Пратта — это не новый подход. :)
Но он вроде бы не очень популярен.
Как минимум интересной может быть особенность линтера в плане расширяемости.
Не так много статических анализаторов позволяют описывать правила в виде синтаксических шаблонов. См. Как добавить проверки в NoVerify, не написав ни строчки Go-кода.
Так что я думаю польза для разработчиков может быть хотя бы из того, что можно подсмотреть в код и позаимствовать некоторые идеи.
Я постарался собрать список других проектов, которые так или иначе используют шаблоны для статического анализа. Можно туда так же добавить расширения ES Lint и подобные, но всё-таки там не AST-шаблоны, а своеобразный DSL из ключей-значений.
Также несколько раз делались разборы Open-Source проектов через NoVerify, после чего меинтейнерам отправлялись патчи с исправлениями багов. Тоже некоторая польза сообществу. :)
Ещё кто-то натолкнулся на эту особенность:
https://utcc.utoronto.ca/~cks/space/blog/programming/GoRangeCopying
https://utcc.utoronto.ca/~cks/space/blog/programming/GoForRangeNudging
С моим опытом не согласуется, но минус за комментарий (не в карму) я поставил из-за того, что ваш комментарий довольно кусачий и некоторых может незаслуженно обидеть.
Решил дать вам знать. Возможно, кто-то еще поставил минус по той же причине.