Здравствуйте, Алексей., Вы писали:
A>>Пусть будет два рабочих дня и ещё умножим на ва, как поступают менеджеры со сроками программистов. Итого 11го числа баги будут исправлены. Ну-ну.
А>Синтаксические ошибки обычно достаточно быстро исправляются. Единственный затык который возможен это проблемы с генератором парсеров, например он что-то не умеет и тогда приходится приделывать костыли.
Да, и нужно учитывать, что "генератор" парсеров наш, т.е. делается нами же. Плюс — это не отдельное приложение, а макрос, что сильно упрощает его разработку, и как следствие, его развитие.
Так что если что-то будет нужно — прикрутим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Silver_s, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет. S_> Что пашет? AST разбирается без выброса Exception.
Исключения — то уже явный баг. Само собой разумеется их точно быть не должно.
В даннымй момент речь идет о парсере. Он только разбирает код (текст) в AST. И делает это без сообщений об ошибках.
S_>Или эти исходники без правки, целиком компильнулись (парсинг вместе с Немерлевской кодогениерацией) в работающее приложение?
Это уже следующий этап. Для этого мы сделали плагин к компилятору немерла (который использует этот парсер). Полностью это вообще невозможно потому что языки не на 100% совместимы. Но думаю, что через месяцок можно будет проект средней руки перекомпилировать немерлом. Пока что некоторый код вызывает проблемы. Но многое компилируется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?
Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).
Здравствуйте, nikov, Вы писали:
VD>>Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно
N>Вот поэтому парсер должен выдавать на нём ошибку. А он не выдаёт.
Ну, так ты описывай ожидаемое поведение. Телепатия не является нашим коньком .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Влад, препроцессор серьёзная штука как ни крути.
Я в курсе. Хотя по всей видимости во второй версии немерла его не будет (за ненадобностью).
Просто делать как все — писать рукопашную реализацию не хочется. Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
Думаю в ближайшее время поддержка препроцессора появится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?
N>Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).
Я подхожу к этому делу проще. Ошибка все равно появится, так как не удастся создать такой тип. А парсер может использоваться в для очень разных задач. Кроме того важна его скорость. Дополнительные проверки будут понемногу снижать скорость. Так что лучше это дело на семантику переложить, наверно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
Это как? Псевдокод покажи?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно. WH>Это как? Псевдокод покажи?
Ты бы в Скайпе появлялся ЧАЩЕ, мы бы мы бы тебе Хардкейсом все рассказали.
Нужно следующее.
Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:
Здравствуйте, VladD2, Вы писали:
VD>Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:
Вы с Хардкейсом опять что-то странное придумали.
1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.
Нам нужен их АСТ для подсветки синтаксиса.
2)То что вы сделали вы озвереете отлаживать.
Красивое решение я пока не вижу.
Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Красивое решение я пока не вижу.
WH>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _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'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
Вот это самое что ни на есть кривое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.