Основная концепция таблицы символов является отображением идентификаторов-в-рамки для информации о идентификаторе (тип, использует ...)
Таким образом, любой механизм, который связывает имя (почти всегда строка) с «значением типа» просто отлично в качестве основы. Итак, словари будут работать. (Фактически, хэш-таблицы по ключам идентификатора являются классическим способом реализации этого).
Но вам нужно больше, чем для реальных таблиц символов. Вам необходимо сопоставить каждую такую карту с областью , в которой она действительна. Во многих классических языках, подобных Алголю, такие области вводятся вложенными блоками. На более сложных языках (например, на C++) есть пространства имен и другие сложные структуры области видимости, а отношение карт к областям может потребовать комплексного отображения обратно к коду сума (или узлам AST или тому, что вы используете в качестве представления).
Поиск в в «таблице символов» требует правил о том, как определить текущую область (таким образом, текущую карту идентификатора к типу) и что делать, если идентификатор найден в этой области и что делать, когда он НЕ найден в этой области (обычно, смотрите в другой области, определяемой языковыми правилами). Сложные языки, допускающие перегрузку, могут потребовать нескольких записей в области для представления перегруженных имен; внезапно простого словаря недостаточно, вам может понадобиться дерево вариантов, привязанных к каждому идентификатору, найденному на карте, или более сложное отображение идентификатора с сигнатурными данными в запись области.
Во многих языках, похожих на алгол, «искать в другой области» требует перехода к «лексическому вложению» блоков, поэтому каждая карта должна иметь связь с родительской областью. Сложные языки, такие как C++, могут иметь несколько правил наследования; теперь вы должны иметь возможность определить, какие («родительские») области могут способствовать наследованию, и какой порядок искать родителей. Поскольку сложные языки могут иметь множество различных правил поиска в зависимости от контекста символа, каждой карте идентификатора может потребоваться ее конкретная политика (процедурное присоединение) о том, как она выполняет локальные поиски (например, обрабатывает найденные перегрузки) и как она обрабатывает неудачные запросы.
Так что в то время как словаря достаточно для действительно простой язык с одной областью, на практике вам нужно гораздо больше «структуры» для хранения таблицы символов для сложного языка.
И если вы считаете, что ваш «простой» язык будет иметь только малые экземпляры и, следовательно, вам нужен только один объем, вы будете грубо удивлены тем, что делают ваши пользователи. (Когда-либо видел тысячный оператор SQL SQL). Поскольку экземпляры DSL становятся большими, вам нужно больше правил определения области видимости, чтобы сделать их управляемыми, и в итоге вы столкнетесь с некоторыми или всеми описанными выше сложностями. Подумайте надолго, как вы это делаете.
(Проверьте мою биографию для инструмента для создания DSL, у которого есть оборудование для табличек символов, которое обрабатывает все вышеперечисленное.Однако не реализовано в Python).