Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
>«Причем тут стек? При том.»
Автор, ну неужели ты не видишь логики? В первом случае написал неправильно, а во втором случае правильно.
«при чём»? — при том
Автор, ну неужели ты не видишь логики? В первом случае написал неправильно, а во втором случае правильно.
«при чём»? — при том
Статья-самоучитель по напписанию парсера должна начинаться с маленького, но полноценного примера языка, который вы хотите распарсить. Потом в ней хорошо бы прочитать про этапы разбора (лексический, синтаксический, семантический), потом про способы записи грамматики (БНФ), потом про алгоритмы разбора (LL/LR/LALR), потом про промежуточное представление. А завершиться она должна полным примером реализации парсера и примером генерируемого им IR.
Сейчас же у вас есть только маленький кусочек входных данных, и маленький кусочек кода, которые еще и не связаны между собой, а в качестве «промежуточного представления» генерируется строка (!). Вы сильно поторопились с написанием этой статьи, и в результате для знающих людей она абсолютно бесполезна, а для новичков даже опасна тем, что прививает плохие практики.
Сейчас же у вас есть только маленький кусочек входных данных, и маленький кусочек кода, которые еще и не связаны между собой, а в качестве «промежуточного представления» генерируется строка (!). Вы сильно поторопились с написанием этой статьи, и в результате для знающих людей она абсолютно бесполезна, а для новичков даже опасна тем, что прививает плохие практики.
У меня было желание написать небольшую статью понятным языком (а не книгу — мануал) и рассказать про принцип работы транслятора на примере написанного мной проекта.
Про алгоритмы разбора, разного рода анализаторы и способы записи грамматики люди могут прочитать и так.
Но, согласитесь, приятно прочитать о чем то сложном в простой форме.
Не все пишут на FPC. Моей задачей было рассказать по какому принципу можно написать транслятор, а не закидать читателя кучей кода (!), который возможно и не каждый поймет даже, потому что не будет сидеть разбираться в нем (!).
Считаю, что в статье довольно подробно описаны основные этапы реализации транслятора.
Полный код доступен в репозитории (!).
Примеры входных и выходных текстов тоже (!).
В качестве промежуточного представления в конечном счете генерируется листинг на ассемблер-подобном языке (!), который я описывал в предыдущей статье, чем вам не промежуточное представление?)
Разве моя практика плоха, чтобы её прививать новичкам?(
Цель написания транслятора была поставлена и была успешно выполнена. Да, не самым оптимальным способом и транслятор работает медленнее, чем мог бы. Но тут есть и положительная сторона — разработка транслятора шла в быстром темпе, благодаря такой архитектуре. Да и разве критична скорость трансляции, если в конечном итоге приложение собирается в независимый формат и будет выполняться на ВМ.
Спасибо за комментарий, теперь, если заинтересованные люди увидят его и не поймут половину аббревиатур — они полезут в гугл и прокачают свой мозг.
Про алгоритмы разбора, разного рода анализаторы и способы записи грамматики люди могут прочитать и так.
Но, согласитесь, приятно прочитать о чем то сложном в простой форме.
Не все пишут на FPC. Моей задачей было рассказать по какому принципу можно написать транслятор, а не закидать читателя кучей кода (!), который возможно и не каждый поймет даже, потому что не будет сидеть разбираться в нем (!).
Считаю, что в статье довольно подробно описаны основные этапы реализации транслятора.
Полный код доступен в репозитории (!).
Примеры входных и выходных текстов тоже (!).
В качестве промежуточного представления в конечном счете генерируется листинг на ассемблер-подобном языке (!), который я описывал в предыдущей статье, чем вам не промежуточное представление?)
Разве моя практика плоха, чтобы её прививать новичкам?(
Цель написания транслятора была поставлена и была успешно выполнена. Да, не самым оптимальным способом и транслятор работает медленнее, чем мог бы. Но тут есть и положительная сторона — разработка транслятора шла в быстром темпе, благодаря такой архитектуре. Да и разве критична скорость трансляции, если в конечном итоге приложение собирается в независимый формат и будет выполняться на ВМ.
Спасибо за комментарий, теперь, если заинтересованные люди увидят его и не поймут половину аббревиатур — они полезут в гугл и прокачают свой мозг.
Во время разработки дизайна и реализации языка вы приняли множество решений не на основе фактов и сравнений, а на основе вашего «представления о прекрасном». Поэтому эти решения наивны и неоптимальны, и для pet project это вполне нормально, но проблема в том, что вы на голубом глазу выдаете их как пример для подражания. Для того, чтобы советовать свой подход кому-то другому, его сперва нужно защитить и обосновать, и «мне так было проще» в данном случае не считается за аргумент.
Например, почему вы решили объединять длинные строки в одну, а не просто пропускать символы перевода строки? Почему вы не разделяете текст на лексемы, а работаете с ним как с массивом символов? Почему промежуточное представление — это строка, а не дерево или хотя бы массив объектов?
Например, почему вы решили объединять длинные строки в одну, а не просто пропускать символы перевода строки? Почему вы не разделяете текст на лексемы, а работаете с ним как с массивом символов? Почему промежуточное представление — это строка, а не дерево или хотя бы массив объектов?
>Разве моя практика плоха, чтобы её прививать новичкам?(
Местами — ужасна. Причем заметьте, какой-нибудь LL(1) парсер, сделанный автоматически на базе грамматики, будет содержать кода строк на 20, то есть на порядок проще, то есть весь будет меньше по размеру того, что вы написали для разбора while. И атрибутные грамматики и AST, которые вам очевидно активно не нравятся — вещь на самом деле чрезвычайно простая. Даже с базовой обработкой ошибок.
При этом вся реализация, сделанная на базе правильных алгоритмов, будет правильно же структурирована, а то что вы тут показали — чистой воды каша.
Местами — ужасна. Причем заметьте, какой-нибудь LL(1) парсер, сделанный автоматически на базе грамматики, будет содержать кода строк на 20, то есть на порядок проще, то есть весь будет меньше по размеру того, что вы написали для разбора while. И атрибутные грамматики и AST, которые вам очевидно активно не нравятся — вещь на самом деле чрезвычайно простая. Даже с базовой обработкой ошибок.
При этом вся реализация, сделанная на базе правильных алгоритмов, будет правильно же структурирована, а то что вы тут показали — чистой воды каша.
Mash — так и переводится :D
Возможно в будущем я решусь реализовать парсер с построением AST дерева.
Так уж вышло, что транслятор я писал уровнями, обвешивая код местами не нужными механизмами. Но в итоге получился рабочий код. На русском языке трудно найти стоящую документацию по написанию трансляторов. Я постараюсь это исправить, насколько мне под силу.
Возможно в будущем я решусь реализовать парсер с построением AST дерева.
Так уж вышло, что транслятор я писал уровнями, обвешивая код местами не нужными механизмами. Но в итоге получился рабочий код. На русском языке трудно найти стоящую документацию по написанию трансляторов. Я постараюсь это исправить, насколько мне под силу.
Литература есть, но ориентироваться стоит не на статьи или блоги, а на книги. Могу порекомендовать С.З.Свердлова "Языки программирования и методы трансляции", там очень хорошо рассказано про принципы построения ЯП, заложенные Н. Виртом и в Паскаль и в Модулу и в Оберон.
Не сочтите за агрессию, но сколько Ваших ответов ни читал, постоянно «Всё в репозитории» и т.д. Зачем тогда вообще статьи, если «Всё в репозитории есть»?
Касательно того, о чем Вам говорят: нужно различать сложное в простой форме и короткие записки о сложном. У Вас второе. Вроде примерно всё понятно, но смотрится это не цельно. На Хабре есть несколько статей по компиляторам и пр., которые гораздо лучше и подробнее, без потери простоты объяснения, разбирают что да как.
Касательно того, о чем Вам говорят: нужно различать сложное в простой форме и короткие записки о сложном. У Вас второе. Вроде примерно всё понятно, но смотрится это не цельно. На Хабре есть несколько статей по компиляторам и пр., которые гораздо лучше и подробнее, без потери простоты объяснения, разбирают что да как.
Если перед парсингом вы соединяете многострочные выражения в единые длинные строки, как тогда у вас организовано формирование сообщений об ошибках, ведь информация о текущей строке/колонке должна теряться?
Ваше решение обладает самобытностью, оно доведено до весьма приличного уровня и в принципе заслуживает уважения. Но я бы все же рекомендовал рассмотреть более «классический» вариант: Обычно входные данные разбиваются на токены лексическим анализатором, при этом каждому токену можно присвоить его местоположение (строка, столбец). В дальнейшем парсер анализирует последовательности токенов на предмет принадлежности грамматике, и, при нахождении «неправильного» токена, может извлечь нужную информацию о местоположении для указания точного места ошибки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем свой язык программирования, часть 3: Архитектура транслятора. Разбор языковых структур и математических выражений