Здравствуйте, WolfHound, Вы писали:
WH>Сделал поддержку нескольких стартовых правил. WH>Сейчас поддерживаются точки расширения и простые правила.
С первым понятно. Можно подробностей про "простые правила"? Их как-то надо помечать? Или все правила могут быть стартовыми (это сколько же тогда будет публичных методов?)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>С первым понятно. Можно подробностей про "простые правила"? Их как-то надо помечать? Или все правила могут быть стартовыми (это сколько же тогда будет публичных методов?)?
Надо помечать.
[StartRule]
start : Ast = s expr !any;
[StartRule]
expr : Ast;
rounds is expr = '('s expr ')'s;//(*)
Здравствуйте, VladD2, Вы писали:
VD>Осталось сделать динамическую расширяемость и можно начинать эксперименты по созданию немерле на новом парсере!
Это я сейчас ковыряю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>А можно делать расширяемым стартовое правило (в смысле, проблем не будет,
Вроде можно. Никаких проблем быть не должно.
VD>там же предикат)?
И что?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>А можно делать расширяемым стартовое правило (в смысле, проблем не будет, WH>Вроде можно. Никаких проблем быть не должно.
А проверка на то что есть хотя бы одно стартовое правило есть? А то я что-то гляжу код и не вижу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А проверка на то что есть хотя бы одно стартовое правило есть? А то я что-то гляжу код и не вижу.
Нету. Ща пофикшу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Нету. Ща пофикшу.
Хотя если подумать, то может она и не нужна.
Ибо люди могут захотеть сделать исключительно расширяющую грамматику не рассчитанную на самостоятельный разбор.
Например так:
[ParserGrammar(Options = EmitDebugSources,
grammar
{
using CalcParser;
prefixInc is expr = "++"s expr : 200;
postfixInc is expr = expr : 200 "++"s;
}
)]
class IncParser : IGrammar
{
prefixInc(op : NToken, v : Ast) : Ast { Ast.UOp(GetText(op), v) }
postfixInc(v : Ast, op : NToken) : Ast { Ast.UOp(GetText(op), v) }
}
Тут даже атрибут повесить некуда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Чёто мне это ручное задание IGrammar совсем не нравится. Вешай как ты лучше его сам, в макросе. Зачем людей лишними знаниями обременять?
Это все временно.
В теме же написано что это альфа.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Кстати, этот пример отчетливо демонстрирует, что s нужно как-то стандартизировать. Или здесь подразумевается, что новой грамматике доступны правила расширяемой? В общем, откуда s?
А так же становится очевидным, что имеет смысл уже сейчас реализовать идею с умолчальными s и S для правил:
Подразумевается, что после каждой синтаксической конструкции могут идти пробельные символы (т.е. как бы каждое подправило дополняется правилом s разбирающим ноль или более незначащих символов вроде пробелов и концов строк). Если подправило заканчивается на букву, подчеркивание или цифру (в понятии Unicode-категорий), то подразумевается, что такое подправило дополняется правилом S (которое содержит предикат не допускающих наличия в следующем символе цифр и букв и идущие за ним правило s). Таким образом, синтаксис, описываемый в макросах, не содержит специальных конструкций для разбора пробельных символов, но при этом автоматических их вставляет. Кроме того можно будет отключить эту функциональность (добавив к декларации макроса атрибут ExplicitSpaces) и разбираться с пробельными символами вручную. При этом для описания пробельных символов нужно будет использовать предопределенные макросы s и S (описывающие правила разбора пробельных символов).
А то в 99% правил будет один и тот же шаблон с пробельными символами. Зачем заставлять пользователей долбить его из раза в раз?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Или здесь подразумевается, что новой грамматике доступны правила расширяемой?
Подумал... доступность правил из внешней грамматики нужна. Например, при описании своего типа хотелось иметь возможность использовать правила модификаторов и атрибутов описанных в исходной грамматике.
Можно, конечно, заложиться на ручную пометку таких правил, но боюсь, что это ненужный геморрой для писателей грамматик.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Нужно: Придумать название алгоритму. WH>Ибо штука получилась очень мощная.
Можно попробовать придумать какое-то производное от lupus (волк) или canis(собака).
Почему так? Ну во-первых, раз ты это написал тут есть неявный отсыл к твоему нику, а во-вторых парсинг, ведение носом по строке, похож на действия собаки-ищейки.
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Предлагаю назвать ETD — Extendeble Top-Down (как вариант Excellent). Запоминается хорошо. Произносится легко. А суть алгоритма в названии один хрен не отразить. Слишком там много всего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.