Re[25]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:11
Оценка:
Здравствуйте, nikov, Вы писали:

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


Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:11
Оценка:
Здравствуйте, hardcase, Вы писали:

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


А почему? Думаю — это не должно быть проблемой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Парсер C# на Nemerle
От: nikov США http://www.linkedin.com/in/nikov
Дата: 08.11.10 15:35
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Вот поэтому парсер должен выдавать на нём ошибку. А он не выдаёт.
Re[24]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:37
Оценка:
Здравствуйте, 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, потенциально, позволяет довольно легко реализовать условный парсинг, что нужно для реализации препроцессора.
Декларативность — это наше все!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:42
Оценка:
Здравствуйте, Алексей., Вы писали:

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


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


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

Так что если что-то будет нужно — прикрутим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:43
Оценка:
Здравствуйте, adontz, Вы писали:

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



Только что проверил. Практически все указанное исправлено: см. здесь
Автор: VladD2
Дата: 08.11.10
.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:49
Оценка:
Здравствуйте, nikov, Вы писали:

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


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

Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 15:53
Оценка:
Здравствуйте, Silver_s, Вы писали:

VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.

S_> Что пашет? AST разбирается без выброса Exception.

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

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

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


Это уже следующий этап. Для этого мы сделали плагин к компилятору немерла (который использует этот парсер). Полностью это вообще невозможно потому что языки не на 100% совместимы. Но думаю, что через месяцок можно будет проект средней руки перекомпилировать немерлом. Пока что некоторый код вызывает проблемы. Но многое компилируется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Парсер C# на Nemerle
От: adontz Грузия http://adontz.wordpress.com/
Дата: 08.11.10 15:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Влад, препроцессор серьёзная штука как ни крути.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[26]: Парсер C# на Nemerle
От: nikov США http://www.linkedin.com/in/nikov
Дата: 08.11.10 15:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).
Re[27]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 16:27
Оценка:
Здравствуйте, nikov, Вы писали:

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


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


Ну, так ты описывай ожидаемое поведение. Телепатия не является нашим коньком .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 16:30
Оценка:
Здравствуйте, adontz, Вы писали:

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


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

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

Думаю в ближайшее время поддержка препроцессора появится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 16:33
Оценка:
Здравствуйте, nikov, Вы писали:

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


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


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


Я подхожу к этому делу проще. Ошибка все равно появится, так как не удастся создать такой тип. А парсер может использоваться в для очень разных задач. Кроме того важна его скорость. Дополнительные проверки будут понемногу снижать скорость. Так что лучше это дело на семантику переложить, наверно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Парсер C# на Nemerle
От: WolfHound  
Дата: 08.11.10 16:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Это как? Псевдокод покажи?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 17:07
Оценка:
Здравствуйте, 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);
    }
  ...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Парсер C# на Nemerle
От: WolfHound  
Дата: 08.11.10 18:56
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

Вы с Хардкейсом опять что-то странное придумали.
1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.
Нам нужен их АСТ для подсветки синтаксиса.
2)То что вы сделали вы озвереете отлаживать.

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

Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: Парсер C# на Nemerle
От: _FRED_ Черногория
Дата: 08.11.10 19:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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


То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).
Help will always be given at Hogwarts to those who ask for it.
Re[32]: Парсер C# на Nemerle
От: hardcase Пират http://nemerle.org
Дата: 08.11.10 20:48
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


Их есть в Nemerle.
Но сейчас она не вписывается в механизм работы парсера, и пока поддержки её в C# не будет.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[27]: Парсер C# на Nemerle
От: hardcase Пират http://nemerle.org
Дата: 08.11.10 20:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Когда начинал работу над записью грамматики PEG был в зачаточном состоянии.
А теперь я думаю, что обработка таких эскейпнутых крокодилов может некисло затормозить парсер — дело ли, на кажом символе идентификатора проверять \u.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[31]: Парсер C# на Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.11.10 20:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.

WH>Нам нужен их АСТ для подсветки синтаксиса.

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

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

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


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

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


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

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


Вот это самое что ни на есть кривое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.