Здравствуйте, VladD2, Вы писали:

VD>Это проблема не парсера, а С++. В его же стандарте описано как разрешать эту неоднозначность. Типизатор просто должен проверить первый идентификатор по таблице символов. Если это тип, то это описание переменной. Если это не тип, то это выражение. Вторая ветка просто отбрасывается.


"Типизатор просто должен проверить первый идентификатор по таблице символов"
1) почему это не делать на уровне парсера. Тогда этот спор не о чем
2) Вольхаунд говорил, о том, что зависимость может быть и ниже по коду, тогда просто таблицей символов не решишь.
3) относительно хаскеля, с шарпа и т д как я понимаю нет таких проблем. как с пхп и другими динамическими.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, VladD2, Вы писали:

VD>>Это проблема не парсера, а С++. В его же стандарте описано как разрешать эту неоднозначность. Типизатор просто должен проверить первый идентификатор по таблице символов. Если это тип, то это описание переменной. Если это не тип, то это выражение. Вторая ветка просто отбрасывается.


А>"Типизатор просто должен проверить первый идентификатор по таблице символов"
А>1) почему это не делать на уровне парсера. Тогда этот спор не о чем

это не задача парсера, данный вид неоднозначности можно решить когда построено уже все дерево, неполное дерево это не дерево, оно должно быть завершено и описывать этот модуль с его заголовочными файлами, чтобы понять что имелось в виду у парсера не хватает информации, она появляется когда уже построено все дерево и мы можем по нему построить таблицу символов и понять что имелось в виду в этом выражении, что это переменная или тип, в следующей фазе обработки дерева. С++ заложил такую неоднозначность в язык и стандарт определяет как это разрешается, по другому никак, есть синтаксические неоднозначности которые парсер может разрешить самостоятельно по другим признакам, я говорил как то о приоритете синтаксиса, как например в ПЕГ когда если первое правило сработало оно и выбирается в качестве текущей альтернативы, сейчас есть предикаты, которые позволяют тоже по синтаксическим критериям выбирать тот или иной вариант, в данном случае парсер тоже может посмотреть срабатывают ли какие то правила, есть ли какие то токены и выбрать ту или иную алтернативу, но в данном случае это откладывается до получения более полной информации из таблицы символов, до следующей фазы обработки дерева, то есть до типизации.

В найтре в грамматику можно встраивать какое то преобразование дерева и работу с символами, хотя я не сторонник в грамматике описывать это, но часть задач до типизации или как начало типизации можно решить там, но это уже не парсинг а обработка дерева, после, сделанная на основе методов на АСТе, можно строить информацию символов в несколько проходов уже там. Предполагается в будущем отдельный DSL для типизации.

А>2) Вольхаунд говорил, о том, что зависимость может быть и ниже по коду, тогда просто таблицей символов не решишь.
если ниже по коду, то таблица символов на момент разрешения должна иметь информацию ниже по коду, если это класс то сначала он целиком и парсится в дерево, пускай имеющее и неоднозначности, и можно построить таблицу символов по тому что есть, на следующем этапе по имеющей полной информации по этому файлу, включая заголовки выше, разрешаем неоднозначности, в обработке нас никто не ограничивает.

А>3) относительно хаскеля, с шарпа и т д как я понимаю нет таких проблем. как с пхп и другими динамическими.
Не знаю насчет хаскеля, но шарп более однозначный язык, синтаксических неоднозначностей мало, доисторические вещи типа препроцессора С выкинуты, в том виде как он используется в С++, поскольку ссылается на прекомпилированные .net сборки компиляция очень быстрая, и ему не требуется доступ ко всему коду из заголовков и построение этого в синтаксические деревья с одновременной компиляцией, что затормаживает С++ компиляцию, там есть свои задачи и сложности и их решают, с парсингом этих языков проблем быть не должно. Динамические языки компилируются на ходу, поэтому синтаксис более делается однозначный, а связывание и ошибки многие переносятся в рантайм

Здравствуйте, Аноним, Вы писали:

А>"Типизатор просто должен проверить первый идентификатор по таблице символов"
А>1) почему это не делать на уровне парсера. Тогда этот спор не о чем

Потому что это не вяжется с алгоритмами работы генерализованного парсера. Плюс для реализации подобной схемы нужно много приседаний.

А>2) Вольхаунд говорил, о том, что зависимость может быть и ниже по коду, тогда просто таблицей символов не решишь.

Вольфхаунд говорит об общем случае. В случае С++ все и так довольно однозначно. Но для этого нужно иметь автоматный или LL(1) парсер и встроенную систему разрешения неоднозначностей. Это накладывает ограничения на описание грамматики и создает много других сложностей.

Nitra позволяет описывать грамматики не заморачиваясь на приведение их соответствие требованиям LL(1) или LALR(1). Кто пытался создать такие грамматики, тот знает какой это геморрой.

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

А>3) относительно хаскеля, с шарпа и т д как я понимаю нет таких проблем. как с пхп и другими динамическими.

У C# грамматика однозначная (в основном, контекстно свободная), но требуется в нескольких местах использовать синтаксические предикаты.

С Хаскелем не скажу, но скорее всего тоже проблем нет. Разве что отступный синтаксис осложняет дело.