1)Из-за того что правило кто длиннее тот и прав в некоторых случаях вело себя весьма странно сделал новое правило выбора победившего правила если несколько правил сумели распарить код.
Теперь парсер ведет себя очень интуитивно.
Здравствуйте, WolfHound, Вы писали:
WH>1)Из-за того что правило кто длиннее тот и прав в некоторых случаях вело себя весьма странно сделал новое правило выбора победившего правила если несколько правил сумели распарить код.
Неплохо бы описать это окружающим.
WH>2)Сделал загрузку грамматик.
Что с обработкой ошибок?
Что с оптимизациями?
Насколько это дело протестировано? Можно пробовать соорудить парсер немерла?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Неплохо бы описать это окружающим.
Победившее правило определяется на основе поэлементного сравнения последовательностей верхнего уровня.
Победившим считается то правило, которое на очередном шаге продвинулось дальше.
Например:
раньше вот эти два правила
neg is expr = '-'s expr : 100;
prefixDec is expr = "--"s expr : 200;
на таком тексте
--1
конфликтовали. Ибо съедали одно и то же количество текста.
И в зависимости от фазы луны дерево разбора получалось таким
(-(-(1))) или таким (--(1))
Сейчас будет выбран второй вариант.
ибо -- съедает текста больше чем —
Еще интереснее получалось с текстом типа:
1---1
сейчас оно разбирается так ((1)--)-(1)). Таким же образом ведут себя и все остальные языки.
Раньше оно разбиралось вот так
((1)-(--(1))) или так ((1)-(-(-(1))))
Это происходило по тому, что бинарный — съедал больше текста чем --.
Но и это не самое веселое поведение старой схемы.
Вот такой код 1-1---1 разбирался так (((1)-((1)--))-1).
А все по тому, что бинарный — лево-ассоциативен и при переборе постфиксных правил для второй 1 не использовался.
В результате парсер начал вести себя близко к тому, как человек разбирает текст.
VD>Что с обработкой ошибок?
Я сейчас как раз над этим думаю.
Там не все так просто.
VD>Что с оптимизациями?
Это просто. Но я буду делать потом.
Чтобы оптимизации под ногами не путались, когда я буду делать основную логику.
А как ее делать я пока не до конца придумал.
VD>Насколько это дело протестировано?
Арифметические выражения разбирает.
Грамматики подгружает.
Думаю немерле тоже разберет.
Но если что я на связи.
VD>Можно пробовать соорудить парсер немерла?
Ломающие изменения все еще запланированы.
В частности нужно уйти от чисилок при задании силы связывания.
Но попробовать можно. Исправление ошибок вызванных изменениями будет весьма прямолинейным.
Заодно будет, на чем протестировать логику обработки ошибок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>В результате парсер начал вести себя близко к тому, как человек разбирает текст.
Что значит "близко". Все же есть не состыковки?
VD>>Что с обработкой ошибок? WH>Я сейчас как раз над этим думаю. WH>Там не все так просто.
Что за проблемы?
VD>>Что с оптимизациями? WH>Это просто. Но я буду делать потом.
Я поглядел код и не очень понравилось, что постоянно в цикле вызываются:
curOffsets.Clear();
и
bestOffsets.CopyFrom(curOffsets);
WH>Грамматики подгружает.
Вот по эту поводу нужны пояснения. В тесте в основной грамматике CalcParser есть два импорта:
using IncParser;
using NumParser;
В зависимой грамматике IncParser есть импорт:
using CalcParser;
Зачем импорты в основной грамматике? Ведь получается рекурсивный импорт.
Такое ощущение что ты делаешь не то, что нужно. Нам нужно иметь возможность расширять основную грамматику динамически.
Чтобы спарсив директиву using у нас подгружались новые правила. Не будет с этим проблем?
В общем, хотелось бы деталей.
VD>>Можно пробовать соорудить парсер немерла? WH>Ломающие изменения все еще запланированы. WH>В частности нужно уйти от чисилок при задании силы связывания. WH>Но попробовать можно. Исправление ошибок вызванных изменениями будет весьма прямолинейным. WH>Заодно будет, на чем протестировать логику обработки ошибок.
ОК, после нового года займемся этим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>В результате парсер начал вести себя близко к тому, как человек разбирает текст. VD>Что значит "близко". Все же есть не состыковки?
Я пока не нашёл. А близко по тому, что хрен его знает как на самом деле человек текст парсит. Да и все ли его одинаково парсят?
WH>>Я сейчас как раз над этим думаю. WH>>Там не все так просто. VD>Что за проблемы?
Что делать с ошибками при удалении грамматики не ясно.
Лучшее место для хранения MaxRollbackPos это само правило.
Но правила удаляются вместе с грамматикой.
А при раскрутке стека все добавленные using'ом грамматики удалятся.
VD>Я поглядел код и не очень понравилось, что постоянно в цикле вызываются:
Потом подумаю, что с этим делать.
В любом случае я не стану откатываться на приоритетный выбор или кто длиннее то и прав. Они неадекватны.
VD>Зачем импорты в основной грамматике? Ведь получается рекурсивный импорт.
Я тестировал рекурсивный импорт.
Это может быть полезно, если человек одну грамматику на несколько частей разбить хочет.
VD>Такое ощущение что ты делаешь не то, что нужно. Нам нужно иметь возможность расширять основную грамматику динамически. VD>Чтобы спарсив директиву using у нас подгружались новые правила. Не будет с этим проблем?
Это все есть.
Сейчас внутри правила должен работать вот такой хак (не проверял):
Здравствуйте, WolfHound, Вы писали:
WH>Еще интереснее получалось с текстом типа: WH>1---1
Излишнее цитирование удалено.
Не сочти меня идиотом, но такое выражение вообще не должно разбираться!!!!!!!
--- это один оператор, а значит должен искаться именно он, а не пытаться интерпретировать его иначе будет куча непонятных ошибок!
Здравствуйте, Аноним, Вы писали:
А>Не сочти меня идиотом, но такое выражение вообще не должно разбираться!!!!!!! А>--- это один оператор, а значит должен искаться именно он, а не пытаться интерпретировать его иначе будет куча непонятных ошибок!
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Аноним, Вы писали:
А>>Не сочти меня идиотом, но такое выражение вообще не должно разбираться!!!!!!! А>>--- это один оператор, а значит должен искаться именно он, а не пытаться интерпретировать его иначе будет куча непонятных ошибок!
DR>2*-1 тоже не должно разбираться?
Если парсер не сможет разбирать подобные выражения без скобок, то будет непригоден для подавляющего большинства существующих языков, в том числе Немерле и C#.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Аноним, Вы писали:
А>>2*(-1)
DR>Если парсер не сможет разбирать подобные выражения без скобок, то будет непригоден для подавляющего большинства существующих языков, в том числе Немерле и C#.
Здравствуйте, Аноним, Вы писали:
А>Иметь не предсказуемую компиляцию лучше?
в том и смысл, что предсказуемую. Открой C# и попробуй!
var a = 4;
var b = 8;
var c = a---b;
Console.WriteLine(c);
ПРЕДСКАЗУЕМО!
хотя конечно плохой стиль...
Re[9]: Обновление ParserGenerator'а
От:
Аноним
Дата:
29.12.11 07:56
Оценка:
Здравствуйте, para, Вы писали:
P>Здравствуйте, Аноним, Вы писали:
А>>Иметь не предсказуемую компиляцию лучше? P>в том и смысл, что предсказуемую. Открой C# и попробуй! P>
P>var a = 4;
P>var b = 8;
P>var c = a---b;
P>Console.WriteLine(c);
P>
Здравствуйте, WolfHound, Вы писали:
WH>Что делать с ошибками при удалении грамматики не ясно. WH>Лучшее место для хранения MaxRollbackPos это само правило.
Ну, и помещай куда-то в парсер ссылку на самое правило.
MaxRollbackPos и соответствующее ему правило должно накапливаться по мере продвижения по строке.
WH>Но правила удаляются вместе с грамматикой. WH>А при раскрутке стека все добавленные using'ом грамматики удалятся.
Дык запоминай самые длинно продвинувшиеся.
VD>>Я поглядел код и не очень понравилось, что постоянно в цикле вызываются: WH>Потом подумаю, что с этим делать. WH>В любом случае я не стану откатываться на приоритетный выбор или кто длиннее то и прав. Они неадекватны.
Я обратил твое внимание на потенциальную проблему производительности. С ней явно надо что-то делать.
WH>Сейчас внутри правила должен работать вот такой хак (не проверял): WH>
WH>В результате парсер начал вести себя близко к тому, как человек разбирает текст.
возможно получить альтернативные, менее приоритетные варианты разбора синтактико-лексического дерева?
напр. может не устроить приоритетный по соображениям контекста, и нужно запросить следующий, проверить, следующий, ..
это было бы именно как разбирает человек.
Здравствуйте, <Аноним>, Вы писали:
А>Не сочти меня идиотом, но такое выражение вообще не должно разбираться!!!!!!! А>--- это один оператор, а значит должен искаться именно он, а не пытаться интерпретировать его иначе будет куча непонятных ошибок!
Так работают чуть менее чем все языки программирования.
Без этих наворотов не разобрать C#, Java,... и многое другое.
Так что нужно соответствовать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Я обратил твое внимание на потенциальную проблему производительности. С ней явно надо что-то делать.
Я обратил на нее внимание, когда писал этот код. И тоже подумал, что с ней надо что-то делать.
VD>А где и как брать этот CalcParser.Grammar.StaticDescriptor?
CalcParser это тот класс, на который вешается макрос.
Grammar это вложенный класс, в который набивается чуть менее чем весь генерируемый код.
StaticDescriptor это статическое свойство возвращающее GrammarDescriptor.
Объекты типа GrammarDescriptor умеют создавать объекты грамматики и содержат описание самой грамматики.
VD>Чтобы думать надо сначала узнать детали всего этого процесса. Опиши по подробнее что и как. Как взять правило от парсера? И т.п.
Парсеру можно сказать:
PushState() : void — Запоминает набор грамматик.
PopState() : void — Откатывает набор грамматик к предыдущему состоянию.
AddGrammar(descriptor : GrammarDescriptor) : void — Добавляет новую грамматику в парсер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
WH>Так работают чуть менее чем все языки программирования. WH>Без этих наворотов не разобрать C#, Java,... и многое другое. WH>Так что нужно соответствовать.
Это должно быть явно указано в грамматике, если язык позволяет такое скотство, но делать это дефолтом?
Хотя с учётом некоей близости C# и Nemerle это, возможно, оправдано.
Здравствуйте, VoidEx, Вы писали:
VE>Это должно быть явно указано в грамматике, если язык позволяет такое скотство, но делать это дефолтом?
Это поведение чуть менее чем всех языков. И всех известных мне генераторов парсеров.
VE>Хотя с учётом некоей близости C# и Nemerle это, возможно, оправдано.
Вот немерле как раз ведет себя иначе. Он любую последовательность операторных символов считает одним оператором.
Из-за этого тут даже флейм был.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
