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

N>

N>using y = List<int<int>>;
N>

Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно

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

H>Эскейпы в именах \uXXXX не поддерживаются (только в литералах).

А почему? Думаю — это не должно быть проблемой.

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

VD>Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно

Вот поэтому парсер должен выдавать на нём ошибку. А он не выдаёт.

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

N>Такой код не распарсился:

N>1)...
N>2)...
N>3)...
N>4)...
N>5)...
N>На таком упало по OutOfMemoryException:...

Это все исправлено.

N>Здесь без ошибок распарсил грамматически некорректный код:

N>1)
N>

N>class A
N>{
N>    object x = List<List<>>.Foo;
N>}
N>

Это пока что проходит. Возможно баг надо отлавливать в семантике.

N>2)...
N>3)...

Тоже исправлено.

N>Директивы препроцессора вообще не работают (пока не реализованы?)

Ага. Для его красивой реализации нужно немного доработать парсер. Делать так же как это делают в АНТЛР (т.е. врукопашную) не хочется.

PEG, потенциально, позволяет довольно легко реализовать условный парсинг, что нужно для реализации препроцессора.
Декларативность — это наше все!

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

A>>Пусть будет два рабочих дня и ещё умножим на ва, как поступают менеджеры со сроками программистов. Итого 11го числа баги будут исправлены. Ну-ну.

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

Да, и нужно учитывать, что "генератор" парсеров наш, т.е. делается нами же. Плюс — это не отдельное приложение, а макрос, что сильно упрощает его разработку, и как следствие, его развитие.

Так что если что-то будет нужно — прикрутим.

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

A>А теперь товарищи незвери, называем сроки исправления и придерживаемся этих сроков.


Только что проверил. Практически все указанное исправлено: см. здесь

Автор: VladD2
Дата: 08.11.10

.

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

N>

N>using y = List<int<int>>;
N>

Проверил... Это парсится. Хотя, по-моему, не должно. Семантика этот баг обязана выявить. Так что в принципе можно записать в "фичи".

Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?

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

VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
S_> Что пашет? AST разбирается без выброса Exception.

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

В даннымй момент речь идет о парсере. Он только разбирает код (текст) в AST. И делает это без сообщений об ошибках.

S_>Или эти исходники без правки, целиком компильнулись (парсинг вместе с Немерлевской кодогениерацией) в работающее приложение?

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

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

VD>Только что проверил. Практически все указанное исправлено: см. здесь

Автор: VladD2
Дата: 08.11.10

.

Влад, препроцессор серьёзная штука как ни крути.

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

VD>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?

Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).

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

VD>>Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно

N>Вот поэтому парсер должен выдавать на нём ошибку. А он не выдаёт.

Ну, так ты описывай ожидаемое поведение. Телепатия не является нашим коньком .

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

A>Влад, препроцессор серьёзная штука как ни крути.

Я в курсе. Хотя по всей видимости во второй версии немерла его не будет (за ненадобностью).

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

Думаю в ближайшее время поддержка препроцессора появится.

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

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

VD>>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?

N>Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).

Я подхожу к этому делу проще. Ошибка все равно появится, так как не удастся создать такой тип. А парсер может использоваться в для очень разных задач. Кроме того важна его скорость. Дополнительные проверки будут понемногу снижать скорость. Так что лучше это дело на семантику переложить, наверно.

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

VD>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
Это как? Псевдокод покажи?

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

VD>>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
WH>Это как? Псевдокод покажи?

Ты бы в Скайпе появлялся ЧАЩЕ, мы бы мы бы тебе Хардкейсом все рассказали.

Нужно следующее.

Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:

  [PegGrammar(
    start,
    grammar 
    {
      ...
      [ManualControl] 
      ppIfTrue  = ppCondition (!ppDirectiveEnd any)* (!(ppElse / ppEndIf) any)* (ppElse / ppEndIf)
      ppIfFalse = ppCondition (!ppDirectiveEnd any)* 
      ppIf      = ppIfTrue / ppIfFalse;
      ...
    }
  )]
  public partial class Parser
  {
    private ppIfTrue(pos : ref int, ppCondition : PpCondition, _ : NToken,  _ : NToken)
    {
      if (Eval(ppCondition))
        _preprocessorState.Pash(true);
      else
         pos = -1; // ... fail
    }

    private ppIfFalse(ppCondition : PpCondition, _ : NToken,  _ : NToken)
    {
      when (Eval(ppCondition))
        _preprocessorState.Pash(false);
    }
  ...

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

VD>Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:
Вы с Хардкейсом опять что-то странное придумали.
1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.
Нам нужен их АСТ для подсветки синтаксиса.
2)То что вы сделали вы озвереете отлаживать.

Красивое решение я пока не вижу.

Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.

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

WH>Красивое решение я пока не вижу.

WH>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.

То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).

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

_FR>То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).

Их есть в Nemerle.
Но сейчас она не вписывается в механизм работы парсера, и пока поддержки её в C# не будет.

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

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

H>>Эскейпы в именах \uXXXX не поддерживаются (только в литералах).

VD>А почему? Думаю — это не должно быть проблемой.

Когда начинал работу над записью грамматики PEG был в зачаточном состоянии.
А теперь я думаю, что обработка таких эскейпнутых крокодилов может некисло затормозить парсер — дело ли, на кажом символе идентификатора проверять \u.

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

WH>Вы с Хардкейсом опять что-то странное придумали.

Как раз самое простое решение.

WH>1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.
WH>Нам нужен их АСТ для подсветки синтаксиса.

А их никто игнорировать не будет. Игнорироваться будет то, что в неактивной части #if-а будет. Студия такой код серым закрашивает.

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

WH>2)То что вы сделали вы озвереете отлаживать.

Что там отлаживать? Просто правило может сфайлить на основании того что оно прочитало из АСТ.

WH>Красивое решение я пока не вижу.

Ты просто не понял озвученного. Оно как раз самое что не наесть красивое и простое в реализации. И что самое главное практически декларативное.

WH>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.

Вот это самое что ни на есть кривое решение.