Работаю с пег парсером не нравится одна вещь, если пишу обработчик для правила который имеет базовый тип например Base, который ссылается на другие правила например так: ruleA / ruleB / ruleC;
и если правило ruleB имеет тип наследника Base.B то получается ошибка, хотя часто нужно именно неявно привести наследника к родителю, то есть чтобы этот код не давал ошибки. Чтобы обойти приходится писать дополнительные обработчики которые тупо приводят наследника к родителю, может это сделать автоматом?

ruleB : Base.B = "правило";
rules : Base = ruleA / ruleB / ruleC;

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

CU>Работаю с пег парсером не нравится одна вещь, если пишу обработчик для правила который имеет базовый тип например Base, который ссылается на другие правила например так: ruleA / ruleB / ruleC;
CU>и если правило ruleB имеет тип наследника Base.B то получается ошибка, хотя часто нужно именно неявно привести наследника к родителю, то есть чтобы этот код не давал ошибки. Чтобы обойти приходится писать дополнительные обработчики которые тупо приводят наследника к родителю, может это сделать автоматом?

CU>ruleB : Base.B = "правило";
CU>rules : Base = ruleA / ruleB / ruleC;

Заводи фичрреквес на гитхабе. Постараемся сделать.

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

VD>Заводи фичрреквес на гитхабе. Постараемся сделать.

Я сделал обычную issue, feature request не знаю как делать.

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

CU>Я сделал обычную issue, feature request не знаю как делать.

Это обычный issue и есть. Просто пометить его атрибутами feature.

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

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

CU>>Я сделал обычную issue, feature request не знаю как делать.

VD>Это обычный issue и есть. Просто пометить его атрибутами feature.

Че то я облазил все не вижу как можно пометить issue аттрибутом.

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

CU>Че то я облазил все не вижу как можно пометить issue аттрибутом.

Забей. Сам поставлю.

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

CU>Работаю с пег парсером не нравится одна вещь, если пишу обработчик для правила который имеет базовый тип например Base, который ссылается на другие правила например так: ruleA / ruleB / ruleC;
CU>и если правило ruleB имеет тип наследника Base.B то получается ошибка, хотя часто нужно именно неявно привести наследника к родителю, то есть чтобы этот код не давал ошибки.

CU>ruleB : Base.B = "правило";
CU>rules : Base = ruleA / ruleB / ruleC;

Посмотрел код... Ничего не получится. Значения для правил возвращаются через ref-параметр. А для них параметр должен иметь конкретный тип.

CU>Чтобы обойти приходится писать дополнительные обработчики которые тупо приводят наследника к родителю, может это сделать автоматом?

Проще делать так:

[PegGrammar(Options = EmitDebugSources, start,
  grammar
  {
    space               = ' ' / '\t';
    [InlineAllSubrules]
    s : void = space*;
    Digit : A           = ['0'..'9']+ s;
    Leter : A           = ['A'..'Z', 'a'..'z']+ s;
    DigitOrLeter : A    = Leter / Digit;
    start : List[A]     = s DigitOrLeter+ s;
  }
)]
public class JsonParser
{
  Digit(token : NToken) : A { A(GetText(token)) }
  Leter(token : NToken) : A { B(GetText(token)) }
}

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

VD>Посмотрел код... Ничего не получится. Значения для правил возвращаются через ref-параметр. А для них параметр должен иметь конкретный тип.
Это обойти просто.
Меняешь такой код:

<[ $(_grammarCompiller.DecorateRuleName(rule.name.Id) : dyn)(pos, text, ref $(result : dyn)) ]>

на такой:

<[
    {
        mutable tmpResult;
        $(_grammarCompiller.DecorateRuleName(rule.name.Id) : dyn)(pos, text, ref tmpResult);
        $(result : dyn) = tmpResult;
    }
]>

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

VD>Посмотрел код... Ничего не получится. Значения для правил возвращаются через ref-параметр. А для них параметр должен иметь конкретный тип.

наверное действительно надо чтобы он сначала выдал тот тип что нужен в ref параметре а потом его привести, у этой задачи должно быть решение, безвыходных ситуаций не бывает, может только для этого потребуется доп информация в дереве что нужно проводить приведение

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

VD>>Посмотрел код... Ничего не получится. Значения для правил возвращаются через ref-параметр. А для них параметр должен иметь конкретный тип.
WH>Это обойти просто.
WH>Меняешь такой код:...

И получаешь дополнительное замедление (копирование и рост стека). Мне кажется оно того не стоит.
По крайней мере нужно заниматься серьезным тестированием производительности, а мне эти заниматься в лом.

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

VD>И получаешь дополнительное замедление (копирование и рост стека). Мне кажется оно того не стоит.
VD>По крайней мере нужно заниматься серьезным тестированием производительности, а мне эти заниматься в лом.

Какой там рост стека если параметры ссылочные, для них мы делаем поддержку приведения и копирование ссылок тоже всего лишь присвоение адресов.

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

CU>Какой там рост стека если параметры ссылочные, для них мы делаем поддержку приведения и копирование ссылок тоже всего лишь присвоение адресов.

Во-первых, параметры не обязаны быть ссылочными. Во-вторых, вызовов то море. Так что рост будет не шуточный.

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