Нет таблицы символов в Go? новый язык

Question

от Google «Go», говорит on its website:

язык был разработан, чтобы быть легко анализировать и может быть разобран без таблицы символов

Я конечно не специалист по этим вопросам , но я думал, что таблица символов является базовой конструкцией, общей для всех компиляторов для языков, использующих переменные, а Go явно использует переменные. Что я не понимаю?

Answer 1

Разбор означает просто определение структуры программы: разделение модуля на заявления/декларации, разбиение выражений на подвыражения и т. Д. Вы получаете древовидную структуру, известную как «дерево синтаксического анализа» или «абстрактное синтаксическое дерево "(AST).

Очевидно, что на C++ требуется таблица символов для синтаксического анализа.

На этой странице обсуждаются некоторые причины why C++ requires a symbol table for parsing.

Конечно, синтаксический анализ является лишь частью компиляции, и вам понадобится таблица символов для полной компиляции.

Однако сам анализ может быть полезен при написании инструментов анализа (например, какой модуль импортирует модули). Таким образом, упрощение процесса синтаксического анализа означает, что проще писать инструменты анализа кода.

Answer 2

Для толкования и компиляции абсолютно необходимы таблички с символами или аналогичные. Это верно для почти всех языков.

В C и C++ даже парсинг для этого языка требуется таблица символов.

Answer 3

@Justice правильный. Чтобы немного расшириться, в C единственная реальная сложная часть рассказывает типы, кроме переменных. В частности, когда вы видите это:

T t; 

Вы должны знать, что T тип для того, чтобы быть законным синтаксического анализа. Это то, что вам нужно искать в таблице символов. Это относительно просто понять, пока типы добавляются в таблицу символов, когда синтаксический разбор продолжается. Вам не нужно делать дополнительную работу в компиляторе: либо T присутствует в таблице, либо нет.

В C++ вещи много, много сложнее. Существует огромное количество двусмысленных или потенциально неоднозначных конструкций. Наиболее очевидным является то, это одна:

B::C (c); 

Помимо того, что это не ясно, если B является class, typedef или namespace, это также не ясно, если C тип и c объект, который type, или если C является функцией (или конструктором), принимающей c в качестве аргумента (или даже если C является объектом с перегруженным operator()). Вам нужна таблица символов для продолжения разбора, хотя по-прежнему можно продолжать достаточно быстро, так как тип символа находится в таблице символов.

Вещи получают много, намного, намного хуже, чем когда шаблоны входят в микс. Если C (c) находится в шаблоне, вы можете не знать в фактическом определении шаблона, если C является типом или функцией/объектом.Это потому, что шаблон может объявить C равным либо типом, либо переменной. Это означает, что вам нужна таблица символов, но у вас нет есть один - и вы не можете есть один, пока шаблон не будет объявлен. Хуже того, не обязательно достаточно иметь только тип символа: вы можете найти ситуации, которые требуют полной информации о типе, который представляет символ, включая размер, выравнивание и другую информацию, относящуюся к машине.

Все это имеет несколько практических эффектов. Двумя наиболее значительными, я бы сказал, являются:

• Компиляция выполняется намного быстрее. Я предполагаю, что Go быстрее компилируется, чем C, а C++ значительно замедляет время компиляции для ситуаций, связанных с множеством шаблонов.
• Вы можете писать парсеры, которые не зависят от наличия полного компилятора. Это очень полезно для анализа кода и для рефакторинга.

Answer 4

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

Например:

INT х = Foo (бар);

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

Answer 5

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

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

В C и C++ для разбора языка требуется таблица символов, так как вам нужно хранить типы и объявления глобальных переменных и функций.

Лексически ограниченные символы не хранятся в symtab, а как индексированный список имен в блочных кадрах, как в функциональных языках. Эти индексы вычисляются во время компиляции. Таким образом, доступ во время работы является немедленным. Выход из области действия делает эти вары недоступными автоматически, поэтому вам не нужно нажимать/поп-имена из пространств имен/symtabs.

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