На данный момент оно работает только с UDF, доступными в СУБД "из коробки". Например, перечисленными в документации. Это обусловлено тем, что список UDF для автодополнения составляется offline.
Не поддержано автодополнение UDF, загруженных через PRAGMA UDF. Если вы часто используете PRAGMA UDF и вам неудобно разрабатывать запросы без автодополнения имен этих функций, то дайте нам знать, например, создав Issue на GitHub и описав свой пользовательский сценарий. Мы рассмотрим и постараемся запланировать.
Мы думали насчет Tree-sitter, но не нашли веских причин взяться за него уже сейчас. Какие важные требования не получится выполнить без Tree-sitter?
У нас есть инструментарий, основанный на ANTLR: форматтер, движок автодополнения. Прочие анализы для IDE-функциональности также планируем реализовывать над сгенерированным из ANTLR-грамматики деревом разбора.
Да, анализы не инкрементальные, но работают достаточно хорошо, а также гарантируется соответствие грамматике языка. Сгенерировать Tree-sitter грамматику по ANTLR не является простой задачей. Поддерживать их в актуальном состоянии требует дополнительных усилий.
Подсветка синтаксиса у нас на регулярных выражениях и тоже работает достаточно хорошо. Мы автоматически генерируем конфигурации подсветки синтаксиса YQL для разных редакторов (Vim, TextMate, IDEA, VSCode) и JS библиотек (Monarch, Shiki, highlight.js) по некоторому абстрактному описанию подсветки синтаксиса языка на регулярных выражениях. Это абстрактное описание является единственным источником истины и состоит из правил, описанных на C++, а также некоторых сгенерированных из той же ANTLR-грамматики, что также упрощает поддержку.
А как вы считаете частоты употребления слов? О каком языке вы говорите: формальном или естественном?
В YQL получилось использовать частоты употребления слов без особых проблем по следующим причинам:
YQL -- формальный язык. Запрос на YQL можно выполнить в целевой системе, чтобы понять, является ли он корректным. Если он корректен, то и слова в нем корректны -- можно считать частоты.
Реализован offline подсчет частот использования слов по корректным запросам из корпуса Query Replay, что исключает опечатки и несуществующие слова.
Query Replay является одним из этапов тестирования YDB. В процессе работы системы в некоторых production окружениях собирается информация о запросах. По данной информации можно определить текст запроса, выполнился ли он успешно, кто выполнил запрос.
Последнее позволяет учитывать запросы именно от людей, а не от ПО.
Для сбора статистики в процессе Query Replay по тексту запроса строится модель запроса для анализа (у нас это пока дерево разбора), по которой уже собираются имена. Причем имена тут больше, чем просто слова, так как модель запроса позволяет их в некоторой степени типизировать.
Список кандидатов формируется из множеств встроенных (например, функции), полученных в процессе семантического анализа запроса (например, именованные выражения) или загруженных с узла СУБД имен (колонки, таблицы). Все источники гарантируют корректность.
Ранжирование применяется уже к сформированному списку кандидатов. Ранжирование является отображением из кандидата (заметим, что он имеет тип) в численную оценку частоты использований. Далее по частоте производится сортировка.
Таким образом, собранные по Query Replay слова никогда не выдаются пользователю.
С опечатками у нас есть только такой моментик. Встроенные в YQL функции могут быть написаны разными способами не только из-за case-insensitivity, но и из-за игнорирования до некоторой степени нижних подчеркиваний. Например, означает одно и то же: StartsWith, startswith, STARTS_WITH, starts_with. Мы, конечно, при подсчете частот и ранжировании нормализуем имена.
Вообще говоря, подсчет статистики на всей истории может не всегда быть эффективным, так как мир меняется, а вместе с ним и предпочтения пользователей. Наверное, чтобы статистика была более эффективной, можно начать с определения периода времени для выборки запросов и, может быть, группировать частоты по признакам пользователей (например, по подразделению).
Автодополнение действительно полезно, оно решает сразу несколько проблем.
Во-первых, ускоряет написание текста, так как позволяет не печатать слова до конца и позволяет делать меньше опечаток.
Во-вторых, позволяет пользователю обнаруживать встроенные в язык имена. Например, функции. Кроме того, говоря о YQL, при помощи автодополнения можно просматривать колонки таблиц и содержимое директорий (в иерархии схемных объектов YDB или Кипарисе YT).
В-третьих, по списку подсказок можно догадываться о том, какие слова и конструкции ожидает в заданной позиции парсер языка. Таким образом, нам не обязательно точно знать синтаксис -- нам что-то о нем, возможно, расскажет автодополнение.
Здравствуйте.
На данный момент оно работает только с UDF, доступными в СУБД "из коробки". Например, перечисленными в документации. Это обусловлено тем, что список UDF для автодополнения составляется offline.
Не поддержано автодополнение UDF, загруженных через PRAGMA UDF. Если вы часто используете PRAGMA UDF и вам неудобно разрабатывать запросы без автодополнения имен этих функций, то дайте нам знать, например, создав Issue на GitHub и описав свой пользовательский сценарий. Мы рассмотрим и постараемся запланировать.
Мы думали насчет Tree-sitter, но не нашли веских причин взяться за него уже сейчас. Какие важные требования не получится выполнить без Tree-sitter?
У нас есть инструментарий, основанный на ANTLR: форматтер, движок автодополнения. Прочие анализы для IDE-функциональности также планируем реализовывать над сгенерированным из ANTLR-грамматики деревом разбора.
Да, анализы не инкрементальные, но работают достаточно хорошо, а также гарантируется соответствие грамматике языка. Сгенерировать Tree-sitter грамматику по ANTLR не является простой задачей. Поддерживать их в актуальном состоянии требует дополнительных усилий.
Подсветка синтаксиса у нас на регулярных выражениях и тоже работает достаточно хорошо. Мы автоматически генерируем конфигурации подсветки синтаксиса YQL для разных редакторов (Vim, TextMate, IDEA, VSCode) и JS библиотек (Monarch, Shiki, highlight.js) по некоторому абстрактному описанию подсветки синтаксиса языка на регулярных выражениях. Это абстрактное описание является единственным источником истины и состоит из правил, описанных на C++, а также некоторых сгенерированных из той же ANTLR-грамматики, что также упрощает поддержку.
Здравствуйте! Спасибо вам за вопрос.
А как вы считаете частоты употребления слов? О каком языке вы говорите: формальном или естественном?
В YQL получилось использовать частоты употребления слов без особых проблем по следующим причинам:
YQL -- формальный язык. Запрос на YQL можно выполнить в целевой системе, чтобы понять, является ли он корректным. Если он корректен, то и слова в нем корректны -- можно считать частоты.
Реализован offline подсчет частот использования слов по корректным запросам из корпуса Query Replay, что исключает опечатки и несуществующие слова.
Query Replay является одним из этапов тестирования YDB. В процессе работы системы в некоторых production окружениях собирается информация о запросах. По данной информации можно определить текст запроса, выполнился ли он успешно, кто выполнил запрос.
Последнее позволяет учитывать запросы именно от людей, а не от ПО.
Для сбора статистики в процессе Query Replay по тексту запроса строится модель запроса для анализа (у нас это пока дерево разбора), по которой уже собираются имена. Причем имена тут больше, чем просто слова, так как модель запроса позволяет их в некоторой степени типизировать.
Список кандидатов формируется из множеств встроенных (например, функции), полученных в процессе семантического анализа запроса (например, именованные выражения) или загруженных с узла СУБД имен (колонки, таблицы). Все источники гарантируют корректность.
Ранжирование применяется уже к сформированному списку кандидатов. Ранжирование является отображением из кандидата (заметим, что он имеет тип) в численную оценку частоты использований. Далее по частоте производится сортировка.
Таким образом, собранные по Query Replay слова никогда не выдаются пользователю.
С опечатками у нас есть только такой моментик. Встроенные в YQL функции могут быть написаны разными способами не только из-за case-insensitivity, но и из-за игнорирования до некоторой степени нижних подчеркиваний. Например, означает одно и то же:
StartsWith,startswith,STARTS_WITH,starts_with. Мы, конечно, при подсчете частот и ранжировании нормализуем имена.Вообще говоря, подсчет статистики на всей истории может не всегда быть эффективным, так как мир меняется, а вместе с ним и предпочтения пользователей. Наверное, чтобы статистика была более эффективной, можно начать с определения периода времени для выборки запросов и, может быть, группировать частоты по признакам пользователей (например, по подразделению).
Автодополнение действительно полезно, оно решает сразу несколько проблем.
Во-первых, ускоряет написание текста, так как позволяет не печатать слова до конца и позволяет делать меньше опечаток.
Во-вторых, позволяет пользователю обнаруживать встроенные в язык имена. Например, функции. Кроме того, говоря о YQL, при помощи автодополнения можно просматривать колонки таблиц и содержимое директорий (в иерархии схемных объектов YDB или Кипарисе YT).
В-третьих, по списку подсказок можно догадываться о том, какие слова и конструкции ожидает в заданной позиции парсер языка. Таким образом, нам не обязательно точно знать синтаксис -- нам что-то о нем, возможно, расскажет автодополнение.