Как упростить компилятор /интерпретатор?

Недавно я написал интерпретатор для операций над разреженными матрицами («разреженный матричный калькулятор») в lex /yacc. Язык по-прежнему очень голые кости и даже не включает в себя структуры управления или параметризованные подпрограммы, но он уже имеет несколько тысяч строк кода, и это не включает в себя классы матриц. В частности, файл yacc имеет длину около двух тысяч строк. Из-за этого мне сложно работать. Является ли это нормальным или есть способ упростить вещи?

Если вы хотите просмотреть мой код, его можно найти по адресу: http://sourceforge.net/projects/msci/files/libpetey/

1 голос | спросил user18850 9 Maypm14 2014, 21:47:52

2 ответа


7

Несколько тысяч строк для синтаксического анализатора + интерпретатора, который действительно делает что-то интересное, не является чем-то необычным. Я просмотрел репо SVN и особенно ваш основная грамматика и заметил различные вещи:

  • У вас есть различные классы полезности, которые будут иметь больший смысл в библиотеке общих алгоритмов. Действительно, реализация быстрой сортировки? IIRC, стандартная библиотека C ++ уже содержит такую ​​функциональность.

    В общем, код кажется очень C-подобным (помимо использования классов) и может извлечь выгоду из создания удобных абстракций с использованием огромного набора функций языка C ++. Я вижу много повторного использования кода с помощью copy & paste.

  • Кажется, вы не создаете АСТ, но разбор и оценка происходят одновременно. Вы должны отделить синтаксический анализ от семантической проверки от интерпретации. Как только ваша грамматика yacc содержит только грамматику, а не половину интерпретатора, она должна стать гораздо более удобной.

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

  • Ваша грамматика также включает справочные сообщения в виде строковых литералов. Фактор таких сообщений в файл ресурсов, а не hardcoding все.

Это был просто быстрый обзор дизайна. Если вас интересует глубокая критика вашего кода, отправьте отрывок вашего кода на Обзор кода .

ответил amon 9 Maypm14 2014, 22:45:29
2

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

  • Используйте функции вместо того, чтобы перебирать все в свой файл yacc. Вы хотите, чтобы файл yacc был только спецификацией вашей грамматики, вставляя как можно больше реализаций в другие файлы. Это позволяет легче отлаживать грамматику, а также помогает легче распознать избыточность.
  • Потратьте лот на время получения вашей грамматики прямо перед тем, как вы начнете работать над реализацией. Я не смотрел на ваш файл в глубину, и мой yacc немного ржавый, но кажется, что есть много повторений, которые можно было бы устранить с лучшей грамматикой. Добавление дополнительных нетерминалов в определенные места может сэкономить вам много работы. В частности, вместо того, чтобы перечислять все возможные комбинации векторных, скалярных и матричных выражений отдельно, попробуйте объединить их в один нетерминал, называемый value или что-то, объедините своих операторов в один нетерминал, называемый op или что-то (или группа, основанная на приоритете оператора), и напишите правила, подобные value op value литий>
  • Вы вкладываете много семантики в свой парсер, где вам следует сосредоточиться главным образом на структуре и реализовать семантику в других файлах. Попробуйте сделать вывод своего парсера только AST . Простые парсеры, подобные тому, который вы найдете в учебниках, можете пропустить этот шаг, но вы найдете для умеренно сложных языков, которым вам действительно нужен дополнительный слой.
ответил Karl Bielefeldt 9 Maypm14 2014, 22:52:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132