LINUX.ORG.RU

Разработка Neparsy - языка представления результатов парсинга

 , , , ,


0

2

Здравствуйте!

Хочу представить на обозрение результаты месяца разработок, а именно язык представления результатов парсинга Neparsy.

Парсинг — это первый этап компиляции любого языка программирования, преобразование текста программы в синтаксическое дерево. После разбора в такое дерево у компилятора ещё много дел: провести семантический анализ, оптимизации, преобразование в ассемблер/машинный код. Идея разбить создание компилятора на несколько частей не нова: компиляторы LLVM состоят из фронтенда, компилирующего язык в универсальный ассемблер некого обобщённого процессора, и бекэнда, производящего оптимизации и преобразование в код целевой архитектуры. Neparsy пытается подойти к задаче с обратной стороны и облегчить разработку именно фронтенда. Он создаёт новый слой абстракции где парсинг уже произведен. Внутри такого слоя облегчается задача трансляции между языками. Разновидности языка Neparsy для представления результатов парсинга различных языков программирования называются диалектами. Например, разрабатываемый в настоящее время диалект для языка D обозначается Neparsy:D.

Разработка компилятора нового языка может быть значительно облегчена, если использовать трансляцию между диалектами Neparsy.

Язык Neparsy имеет очень простой для парсинга Lisp-подобный синтаксис (менее 200 строчек для парсера, для сравнения парсер языка C на bison занимает около 3000 строк).

Вкратце суть Neparsy на примере вызова функции и ещё одной постфиксной функции выглядит так:

(function arg1 arg2 arg3).(postfix-function arg1 arg2)

Помимо этого он имеет одну хитрость:

(func (. arg1 arg2).multi-postfix)

Что аналогично навешиванию постфиксной функции сразу на несколько аргументов, т.е.:

(func arg1.multi-postfix arg2.multi-postfix)

Помимо названия функции или оператора в начале скобки указывается тип через # и метка через @:

(*#unary@label pointer)

Язык не вводит собственных ключевых слов, а использует для этого #типы. Например:

(#. str f1 (#[ 2) f2)

Означает str.f1[2].f2

(#" Литерал строки с пробелами)

А вот пример if-else-if-else конструкции:

(#if
 (условие1).(#body ветка1)
 (условие2).(#body ветка2)
 (#else).(#body else-ветка))

Neparsy также имеет оригинальное графическое представление в виде круговых диаграмм, что и представлено на скриншоте.

За месяц удалось написать:

  • Редактор круговых диаграмм, с клавиатурным управлением. Поддержка мыши — начальная.
  • Парсер кода D, того подмножества D на котором написан сам Neparsy. Причём лексический анализатор и парсер написаны (нарисованы?) непосредственно в редакторе Neparsy.

Репозиторий проекта на github: https://github.com/unDEFER/neparsy

Ветка на языке neparsy: https://github.com/unDEFER/neparsy/tree/neparsy

На скриншоте можно видеть: 4 структуры, функцию typeColor, класс Iface в котором развёрнута функция updateView, а в ней инициализацию двух переменных (большое выражение: double nr = (expr.a1 + expr.a2)/2 - 180), блок «#if», ещё одну переменную ri без инициализации, блок «#while».

В левой панели видны видимые в текущей точке кода переменные и типы. Также там появляется круговая диаграмма с помощью, которой можно бродить по полям и подполям структур.

Управление:

  • Стрелки — навигация
  • Запятая — добавить дочерний узел
  • Пробел — добавить братский узел
  • Точка — преобразовать узел в дочерний
  • Ctrl+Запятая — добавить постфиксный узел/расширить его влияние на узел влево
  • Ctrl+Точка — добавить постфиксный узел/сузить его влияние на узел вправо
  • Shift+Влево, Shift+Вправо — Переместить текущий узел влево или вправо.
  • Ctrl+Стрелки — навигация по полям (когда диаграмма полей видна внизу левой панели)
  • Del — удалить узел и всех потомков
  • Ctrl+Backspace — «отстричь» потомков
  • Ctrl+S — сохранить в формат neparsy
  • Ctrl+D — сохранить в .d-формат (@D модули)
  • Ctrl+L — сгенерировать лексический анализатор из файла описания синтаксиса (@Lexer модули)
  • Enter/Escape — выход из режима редактирования узла

Помимо трансляции между языками есть надежда, что редактор круговых диаграмм окажется удачным решением интерфейса для IDE для мобильных устройств.

>>> Просмотр (1366x768, 258 Kb)

★★★★★

Проверено: hobbit ()

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

Речь не об утопии, речь о по проектной трансляции, о чём писалось выше. А универсальная трансляция без привязки к проекту - да, утопия.

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

приведите пример конструкций и аналогов, сейчас напоминает работу линтера в таком описании, только с разницей что линтер это делает для появившегося сахара в языке по текущим гайдлайнам, а у вас вроде вырисовывается линтер для любого языка в какие-то аналоги каких-то конструкций, и визуализация в кружочках. Я просто пока не могу понять практического смысла в этом, почему мне должно быть проще разбирать выхлоп вашей штуки чем напрямую разбирать синтаксис целевого языка, чем он проще и лучше, даст ли он прирост в скорости и компактности разбора, если да, то на основании чего такие выводы сделаны? В общем, наверное стоит все-таки расписать получше все это дело, а то вопросы множатся, а про скалинг кружочков вы так и не ответили. Но за Д конечно респект, хороший и недооцененный язык простаивает просто потому что корпорациям он не интересен, лучше будем клепать убогий го или что-то подобное.

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

На примере кодовой базы vim, там есть файл hashtab.c.

При трансляции в D вызовы hash_find необходимо заменить на конструкцию «key in ht». hash_add_item в «ht[key] = hi». Ну и так далее.

По поводу скалинга, да, там в интерфейсе всё вертится и разворачивается, чтобы можно было что-то рассмотреть. То что в фокусе и рядом видно хорошо, то что не в фокусе может вовсе сворачиваться и скрываться.

Про подробнее безусловно буду работать над документацией, но сначала хотелось бы почувствовать что в целом синтаксис языка пришёл к некоторому устойчивому состоянию. Потому что пока ещё есть нерешённые вопросы и некоторые аспекты языка по видимому будут меняться.

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

Поэтому я рассматриваю возможность по проектной трансляции. Транслятор будет знать назначение некоторых структур и заменять их на аналоги, если для целевого языка это велосипед. Задача конечно сложная, но я думаю над ней в срезе трансляции vim на D и может быть в будущем возникнут ещё какие-то идеи для упрощения.

Это в смысле под проект нужно будет допиливать транслятор? Не проще ли тогда просто допиливать оттранслированный код (автозаменой например)?

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

Не проще, особенно если речь идёт об активном проекте таком как vim и хочется сделать не просто форк, а периодически забирать патчи из оригинальной ветки.

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

ну… метапрог второе пришествие тогда, но в любом случае продолжайте, может и правда что-то годное выйдет.

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

Тут хотя бы видимый прогресс есть, а не пердолинг с проприетарной виндовой программой

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

В планах попытаться транслировать код Vim с C на D.

sql informix –> sql postgres сможешь?

была бы афигенная фича, я б даже заплатил.

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

По предварительным оценкам, месяца через 4, не раньше. Время самой работы по портированию смогу оценить только имея опыт с vim.

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

так все же расширения стандарта описаны в документации их совсем не много, просто лениво это делать теперь руками? Зачем вообще юзали расширения если гипотетически рассматривалась возможно ливнуть на другую скул субд?

https://www.sqlines.com/ первый ответ на запрос о миграции «с на» пробовали?

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

кому нужен вим?

Прежде всего мне для набора опыта. А так судя по поисковым трендам все валят с C++. Услуги по миграции с C++ на что угодно кажется могли бы быть популярными.

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

ты давно видел БД, которую писали 20 лет, успели нашлепать 7к таблиц и 30к хранимок? и хранимки нифига не по 5 строк. моя любимая тыщщ на 5 наверно.

и это только один «микросервис» ))

у меня такого… вагон. и да, мы пробовали очень много разного :)

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

т.е. 20 лет информикс с его расширениями скула устраивал, а теперь перестал? :]

И что из этого многого и разного ничего не умеет прилично переносить один вид скула с расширениями в другой вид скула с расширениями?

предлагаю следующие 20 лет потратить на приведение всей базы к пур скул стандарту, чтобы потом переезжать было проще )

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

т.е. 20 лет информикс с его расширениями скула устраивал, а теперь перестал? :]

ты прикали, даже SAP перестал устраивать. внезапно.

интересно почему.

20 лет потратить на приведение всей базы к пур скул стандарту

или вот человек выше занят куда более полезным делом.

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

ну о полезности мы узнаем по итогу, метапрог тоже вот думал что очень полезное что-то делает, но и ТС конечно шансов больше, он не сходит с ума и использует нормальные инструменты для достижения целей, а Д так вообще замечательный язык который почему-то не взлетел.

интересно почему.

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

abcq ★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)