Абстрактное дерево против дерева парсера

Мне нужно ваше мнение, чтобы выбрать лучшую альтернативу между выбором: генерировать дерево синтаксического анализатора (ST) или генерировать абстрактное синтаксическое дерево (AST). Это контекст:

Я хочу проанализировать такой язык, как C (просто подмножество C с некоторыми изменениями, чтобы сделать его более ориентированным на псевдокод), но не для того, чтобы перевести его на другой выходной язык / файл, а чтобы выполнить его предложения для анимации процесса его выполнения. (Я использую Qt для рисования). Особенностью этого подмножества C является включение вложенных областей. Мое сомнение в отношении моего выбора между ST и AST вытекает из таблицы символов. Общая идея (используя Boost.spirit):

1. Разбор файла исходного кода с помощью специального анализатора Boost.spirit.
2. Семантические действия создают синтаксическое дерево, просто копию синтаксического дерева исходного кода (или также копию внутреннего синтаксического дерева Boost.spirit, но с моими собственными классами и структурами). Таким образом, нет AST.
3. Имея этот ST в руке, программа читает это синтаксическое дерево в направлении сверху вниз, как показано ниже:
   1. Выполните первое предложение.
   2. Загрузите таблицу символов с новыми значениями (результатом предложения).
   3. Сохраните фактическое состояние таблицы символов в стеке состояний программы.
   4. До 3.1 пока ST полностью не обработан.
   5. Анимировать алгоритм чтения и отрисовки стека состояния программы.

Два рассуждения:

1. Если я работаю с AST, я потерял после анализа информацию о объявлениях переменных, их типах и так далее. Таким образом, мне приходится работать с таблицей символов посредством семантических действий парсера, усложняющих написание и понимание парсера. Более того, мне приходится все время работать с таблицей символов со всеми переменными, независимо от фактической области видимости (если я нахожусь в области действия i, мне нужны только области действия i, i-1, …., 1; не все возможности по всему алгоритму). Это тратит память.
2. В моем стеке состояний программы мне нужны только переменные фактической и предыдущей областей действия, чтобы не усложнять понятность алгоритма посредством анимации. Если я работаю с ST, мне нужно удалить все ненужные символы, прежде чем сохранить его в стеке. Это тратит время.

3. Статическую таблицу символов с областями управления сложнее спроектировать и использовать, чем динамическую таблицу символов. Таблица статических символов должна иметь идентификатор (например) для каждой области и связывать каждый узел дерева с каждым идентификатором. Динамическая таблица символов работает проще, потому что, если я нахожусь в области действия i, нужны только два «вектора» (возможно, двойная очередь и стек):

   • Контейнер (двойная очередь?) С символами и связанной с ним информацией: последняя переменная в контейнере является ближайшей объявленной переменной.
   • Контейнер (стек) целых чисел, показывающий начало (индекс двойной очереди) каждой области.

   Например, для области я:

   • Контейнер 1: [x y z x a b z f a z]
   • Контейнер 2: [0 3 6 8]

   Если я покину область действия i, только я должен стереть последнее целое число и символы с позиции 8 до конца. Дерево остается неизменным.

4. Из-за того, что я должен выполнять каждое предложение во время исполнения, ST облегчает мое исполнение.

Два вопроса:

1. Что лучше тогда?
2. Существуют ли какие-либо формы для извлечения внутреннего дерева Духа или его настройки, чтобы не копировать его?