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

> Будет ли Нитра работать с С++(boost)?

Мы думаем о нативном бэкэнде, но это не ближайшая задача.

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

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

>> Будет ли Нитра работать с С++(boost)?

VD>Мы думаем о нативном бэкэнде, но это не ближайшая задача.

Я о том, сможет ли Нитра разобрать с++ нормально? а в качестве извращеного С++ выступает Boost
Или он будет ограничен более простыми языками

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

А>Я о том, сможет ли Нитра разобрать с++ нормально? а в качестве извращеного С++ выступает Boost
А>Или он будет ограничен более простыми языками

Распарсить сможет без проблем. Алгоритмы на это заточены.

Проблема может возникнуть с поддержкой в IDE. Но это проблема не алгоритмов парсера, а отсутствия модульности и присутствия изощренного препроцессора. С этим все IDE для плюсов мучаются.

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

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

А>>Я о том, сможет ли Нитра разобрать с++ нормально? а в качестве извращеного С++ выступает Boost
А>>Или он будет ограничен более простыми языками

VD>Распарсить сможет без проблем. Алгоритмы на это заточены.

VD>Проблема может возникнуть с поддержкой в IDE. Но это проблема не алгоритмов парсера, а отсутствия модульности и присутствия изощренного препроцессора. С этим все IDE для плюсов мучаются.

Миллионы распарсеных деревьев передавать типизатору в надежде, что одно из них подойдет...
Время распарсивания буста будет равно времени существования вселенной?

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

А>Миллионы распарсеных деревьев передавать типизатору в надежде, что одно из них подойдет...

Нет там никаких миллионов. При условии, что грамматика корректна будет несколько неоднозначностей, которые элементарно разрешаются в один проход (с использованием таблицы символов).

А>Время распарсивания буста будет равно времени существования вселенной?

Сложность кода не влияет на скорость парсинга. На нее влияет исключительно сложность грамматики. Предположительно где-то около 3 метров в секунду (на современной машине) будет, если ошибок нет. Далее дели на размер библиотеки.

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

А>Миллионы распарсеных деревьев передавать типизатору в надежде, что одно из них подойдет...
А>Время распарсивания буста будет равно времени существования вселенной?

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

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

CU>Откуда вы такое взяли про миллионы, неоднозначность означает что будет две разных подветки для неоднозначного выражения, надо выбрать одну из них, в С++ таких неоднозначностей немного, в основном это связано с С кодом, их надо будет разрешить уже позже, если нужна информация из таблицы символов, так уж сделан С++, если выражение заканчивается однозначной лексемой типа ';' или однозначным кодом, то неоднозначное дерево локализовано в виде одного выражения * 2 если неоднозначных деревьев два, дальше по алгоритму восстановления парсер начнет разбор с выдаст нормальное дерево для остальной программы, у С++ не такой большой обьем, для современных мощностей, компиляция сравнима с современными компиляторами, так как С++ задействует много препроцессора и внешних хэдеров. По опыту Найтра довольно шустрый парсер, замедление только если есть серьезные ошибки в коде или еще недописана грамматика, но и этот недостаток алгоритма восстановления думаю исправят в будущем.

a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;
a<b>c;

тут больше миллиона

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

А>тут больше миллиона
А с отдельными деревьями никто и не собирается работать. Парсер создаёт лес деревьев. Типизатор работает с лесом деревьев. И в данном случае комбинаторного взрыва не будет.

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

А>

А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>a<b>c;
А>

А>тут больше миллиона

Непонимаю каким образом здесь миллион деревьев, тут выражение либо создание класса с определением шаблона либо два выражения больше меньше, если не ошибаюсь, и заканчивается неоднозначность ; то есть в каждом выражении две, три версии неоднозначного дерева таким образом, откуда тут миллионы?

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

CU>Непонимаю каким образом здесь миллион деревьев, тут выражение либо создание класса с определением шаблона либо два выражения больше меньше, если не ошибаюсь, и заканчивается неоднозначность ; то есть в каждом выражении две, три версии неоднозначного дерева таким образом, откуда тут миллионы?

Неоднозначности не суммируются, а перемножаются.
Тут 20 строк — значит 2^20 вариантов, а это больше 1 млн.
То, что строчки одинаковые не важно, так как каждый вариант будет передаваться отдельно.
К тому же "<" и ">" операторы и их можно перекрыть, так что код с перекрытыми может быть вполне осмысленный.

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

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

CU>>Непонимаю каким образом здесь миллион деревьев, тут выражение либо создание класса с определением шаблона либо два выражения больше меньше, если не ошибаюсь, и заканчивается неоднозначность ; то есть в каждом выражении две, три версии неоднозначного дерева таким образом, откуда тут миллионы?

А>Неоднозначности не суммируются, а перемножаются.
А>Тут 20 строк — значит 2^20 вариантов, а это больше 1 млн.
А>То, что строчки одинаковые не важно, так как каждый вариант будет передаваться отдельно.
А>К тому же "<" и ">" операторы и их можно перекрыть, так что код с перекрытыми может быть вполне осмысленный.

Неоднозначности не перемножаются, в пределах одного выражения будет две неоднозначности, то есть должно быть две подветки у одного узла

Expr
 Ambiguous
   Template
   MathExpr

каждый узел будет в себе содержать свое выражение которое конфликтует с другим, это в пределах одного выражения. Далее каждое выражение будет лежать в списке Expr* последовательно в таком виде, и здесь нет перемножения:

Expr*
 Expr
  Ambiguous
    Template
    MathExpr

 Expr
  Ambiguous
    Template
    MathExpr

 Expr
  Ambiguous
    Template
    MathExpr

...

';' разрешает неоднозначность и однозначность завершается на одном выражении, все остальные выражения лежат последовательно и экспоненциального роста тут не будет, должно быть 2 * 20 вариантов, миллионов тут не наблюдаю.

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

CU>';' разрешает неоднозначность и однозначность завершается на одном выражении, все остальные выражения лежат последовательно и экспоненциального роста тут не будет, должно быть 2 * 20 вариантов, миллионов тут не наблюдаю.

Как это не будет?
Вполне будет. Тогда питизатору придется выбирать из всех вариантов неоднозначных выражений. Т.е. проблему просто перенес на уровень типизатора.

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

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

CU>>';' разрешает неоднозначность и однозначность завершается на одном выражении, все остальные выражения лежат последовательно и экспоненциального роста тут не будет, должно быть 2 * 20 вариантов, миллионов тут не наблюдаю.

А>Как это не будет?
А>Вполне будет. Тогда питизатору придется выбирать из всех вариантов неоднозначных выражений. Т.е. проблему просто перенес на уровень типизатора.

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

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

А>>Как это не будет?
А>>Вполне будет. Тогда питизатору придется выбирать из всех вариантов неоднозначных выражений. Т.е. проблему просто перенес на уровень типизатора.

CU>Так и не будет потому что там список выражений, то есть плоское выражение, в котором две неоднозначности, неоднозначность с увеличеним числа деревьев будет только внутри одного неоднозначного выражения, которое продолжается вглубь и два родительских неоднозначных узла будут содержать каждый по своей копии дерева, но у нас глубины как раз и нет, два варианта дерева одно состоит из двух выражений как больше и меньше, и создание специализированного класса, а выражения независят друг от друга в разных строках и лежат в списке, никакого экспоненциального роста тут не будет. Вы сначала посмотрите как выглядят парс-деревья, а потом уже думайте над чем будет работать типизатор. Типизатор будет выбирать из двух выражений при обходе каждого узла видя неоднозначность, ничего в этом такого нет.

Понял. Ты прав. Спасибо.

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

А>Понял. Ты прав. Спасибо.

Нет, я был прав.

Как типизатор будет выбирать?
Он выберет первую комбинацию когда все объекты. Проведет типизацию и получит отрицательный результат.
Потом поменяет в последнем(или в первом) на альтернативную ветку и проведет еще раз типизацию и так миллион раз.

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

А>Как типизатор будет выбирать?
А>Он выберет первую комбинацию когда все объекты. Проведет типизацию и получит отрицательный результат.
А>Потом поменяет в последнем(или в первом) на альтернативную ветку и проведет еще раз типизацию и так миллион раз.

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

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

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

А>>Как типизатор будет выбирать?
А>>Он выберет первую комбинацию когда все объекты. Проведет типизацию и получит отрицательный результат.
А>>Потом поменяет в последнем(или в первом) на альтернативную ветку и проведет еще раз типизацию и так миллион раз.

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

Жесть.
Если например в первом должны быть выбрана 1 ветвь, во втором 2 в третьем 2, в четвертом 1 и т д?
Какие из ветвей отбросит типизатор? Не знаю какой глубины там будет проблема, но в ряде случаев ситуация будет даже намного хуже.

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

А>Жесть.
А>Если например в первом должны быть выбрана 1 ветвь, во втором 2 в третьем 2, в четвертом 1 и т д?
А>Какие из ветвей отбросит типизатор? Не знаю какой глубины там будет проблема, но в ряде случаев ситуация будет даже намного хуже.

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

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

А>Как типизатор будет выбирать?
А>Он выберет первую комбинацию когда все объекты. Проведет типизацию и получит отрицательный результат.
А>Потом поменяет в последнем(или в первом) на альтернативную ветку и проведет еще раз типизацию и так миллион раз.

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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