[nem-pl] Rozszerzenia

[Kamil Skalski]

Wednesday 29 of October 2003 00:03, Lukasz Kaiser wrote:

> Nie ma cykli w wywolaniach rekurencyjnych rozszerzen bo one tam wystepuja
> jako funkcje a nie rozszerzenia i nie ma problemu. Jesli zalozysz ze
> nie uzywasz rozszerzen przed ich kompilacja i dolaczeniem jako plik to w
> ogole te problemy powinny zniknac (chyba).

Dokładnie - jedyna możliwość kiedy się trzeba wykrzaczyć, to użycie w kodzie 
rozszerzenia, które używa (choćby pośrednio) tego kodu (zwykłego).

> Eee, cos ty. Wiadomo, bo jest gramatyka jakas i parser wie co po czym
> nastapi i jaki typ w gramatyce ma wyrazenie top-level. No a ty chcesz moc

Tak, pewnie jednak kilka typów rozwazanych syntax tree trzebaby wprowadzić. Bo 
ogolnie ja myslalem o tym co dostaja rozszerzeniajako o top-level 
wyrazeniach. Jednak rozszerzenia moga, czy to przez rekurencyjny rozklad 
drzewa, czy przez zaaplikowanie ich w jakies dziwne miejsca w kodzie, brac 
jako parametry pewne specyficzne czesci drzewa skladniowego.

Wydaje sie, ze wprowadzenie kilku typow drzew (mniej wiecej wg gramatyki) i 
zabronienie uzywania ich w roznych dziwnych miejscach powinno rozwiazac 
problem interpretacji roznych napisow w [< >]. Jednak niestety parser nie ma 
pojecia o typach (a moze moglby miec?).

> funkcji operujacej na drzewie skladniowym. Jesli dodasz nowy znaczek do
> opisu zmiennych , np. $x lub ?x _i_ dopiszesz ich typ, tzn np. ?x : E_if
> (lub jakas ladniejsza nazwa bazujac na gramatyce) to nie powinno byc az
> takich problemow. Wtedy tez powinno dzialac [< x : ?t : type >] (hmm,
> tylko sie dwukropki mieszaja miedzy jezykie a meta, trzeba jakis znaczek
> na meta, moze [< x : $( t : type ) >] albo cos takiego ?). Jest jeszcze

No wiec najprostsza wersja polegalaby na operowaniu czystym drzewm skladniowym
ze wszystkimi jego konstruktorami, ktore wystepuja w kompilatorze/gramatyce.
Wtedy funkcja wygladlaby 
ext f tr =
  match tr with
    E_Assign( va, x) -> E_Assign( f va, f x)
    E_Var(name, type) -> E_Var( name + "Old", type )
    E_Plus(a, b) -> E_Minus( f a, f b)
 ....

Moze by wtedy tyle typo ile konstruktorow, zadenego problemu z parsowaniem, 
nieczym...
Jest tylko jedno ale...
Programista zastanowi sie 10 razy czy zabierac sie za pisanie powyzszej 
funkcji (szczegolnie jesli wziac cala mozliwa gramatyke jezyka i potrzebe 
zapoznania sie z konstruktorami)
niz czegos w stylu:

ext f tp =
  match tr with [
  |  [< va <- x >] -> def (l, r) = (f va, f x); 
                            [< l <- r >]
 |   [< $(name, type) >] -> def newname = name + "Old";
                                            [< $(newname, type) >]
 |   [< a + b >] -> def (l, r) = (f a, f b);
                           [< l - r >]
;

Klopot polega na tym, ze [< >] wymaga niezlego pomieszania jezyka z 
metajezykiem, ktore w rezultacie moze by efektywnie nieczytelne.