[nem-pl] rewrite komplikatora...

[Lukasz Kaiser]

Hej.
 
> Ma te¿ star±, ale chyba zaraz siê wezmê za usuwanie jej u¿ycia.
> 
> Pewnie, ³ikendy oraz ¶wiêta najlepiej sposoruj±.

Sponsoruja czy nie, w kazdym razie masz niezle tempo, moje gratulacje :).

Natomiast jak juz tak przepisujesz, to ja mam takie pytanie/propozycje.
Chodzi o rozszerzenia skladniowe, ale tylko o parsing, pytanie natomiast
jest takie gdzie w tym lezy glowna trudnosc i jak to jest trudne, bo jesli
chodzi o parser.jay to ja sie w ogole nie orientuje.

Propozycja jest taka, zeby zmienic gramatyke w taki sposob, zeby mozna
bylo we wzorcach pisac nie tylko to co jest, ale tez
[<[typ]: kod >], tzn. do jakiejs reguly (jakiejs, bo nie znam aktualnej
wersji) pattern := .... doszloby

pattern := .... | [<expr: branchedExpr >] | [<ty: branchedTy >] ...
(niestety chyba wyliczone wszystkie po kolei, chyba ze masz jakies
wsparcie dla dynamicznego parsowania).

Jesli chodzi o branchedX to reguly bylyby identyczne jak w zwyklej
gramatyce, tylko dodatkowo doszloby wyrazenie $(expr: Expr) (lub tez
jakies inne) dajace mozliwosc wklejania zwyklych wyrazen Nemerle.

Oczywiscie po sparsowaniu trzeba by bylo wszystko pozamieniac odpowiednio
jeszcze przed sprawdzaniem typow, czyli pewnie zrobic jakas funkcje
zamieniajaca parsedExtendedTree na parsedTree. Zamiana bylaby oczywiscie
ideowo dosc prosta, zamieniajac wyrazenia w nawiasach na odpowiadajace im
wzorce korzystajace z wewnetrznych typow, ale pewnie w koncu to wcale nie
byloby az takie proste, na poczatek mozna zawsze zrobic dummy.

- lk