🚀 go-pugleaf

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message 
news:1197596465.19934.36.camel@qrnik...
Dnia 14-12-2007, Pt o godzinie 01:49 +0100, Adam Karpierz pisze:

> To jest trochę inne podejście (też dobre): uproszczona analiza
> kontekstowa tylko dla potrzeb rozpoznawania typedefów, której wyniki
> służą tylko lekserowi. Potem się to robi od nowa z uwzględnieniem
> wszystkich konstrukcji.

Tak.

> Bo można też wykonywać początkowe etapy dalszej analizy równolegle
> z lekserem: budować wszelkie informacje o symbolach widocznych w różnych
> zakresach. Do dokończenia po parsowaniu, a nie do zrobienia od początku.

Dokladnie.

> Zgadza sie.  Tyle ze niekoniecznie do pokreconej struktury tylko
> normalnie w drzewie jako node typedefa
> (node typu: typedef z subnode1: nazwa i subnode2: "rozczesanym" typem).

> Zupełnie nie o to mi chodziło. Problemem nie jest parsowanie samych
> Jeśli mamy coś takiego:
>   a(*b)(c(d));
> to jeśli a był wprowadzone przez typedef, to jest to deklaracja
> wskaźnika b na funkcję zwracającą a, której parametr jest typu c
> (nazwa d nie ma tu znaczenia jako nazwa parametru w typie funkcji).
> Jeśli jednak a nie jest wprowadzone przez typedef, to jest to aplikacja
> funkcji a do wartości odczytanej spod wskaźnika b, gdzie następnie
> wynik jest zaaplikowany do aplikacji c do d. To jest zupełnie inne
> drzewko, tzn. może i strukturalnie wygląda podobnie, ale węzły mają
> zupełnie inną interpretację.

Wlasnie o to chodzi ze strukturalnei (synktatycznie) jest  identyczne.
Mozna sobie wiec przyjac na poczatku dowolne z poddrzew.
Natomiast _faktyczna_ "naprawa" drzewa moze sie juz odbyc
pozniej droga przechodzenai po calym drzewie i "naprawy"
tych wieloznacznych subnodes na wlasciwe (pointer albo call).

Wiec czasami stosuje nodes typu CUSalboCUS
(slawetny przyklad z konstruktorem klasy czy tez funkcja c C++
  ten znany blad z gcc 3.x0 )

> Parsowanie bezkontekstowe ze zunifikowanym drzewkiem
> jest co prawda teoretycznie możliwe (o ile nie mamy narzucone,
> które aspekty składni musimy rozpoznać już na etapie parsowania,
>  a które możemy zostawić na potem), ale być może jest całkiem 
> niepraktyczne.

To zalezy.
Jesli zalezy nam nie na tym _co_ to znaczy ale jedynie jak wyglada
(a mnie w wiekszosci przypadkow o to chodzilo jedynie) to nawet
takie "chore" drzewko starczy jesli robimy jedynei cos w rodzaju
translatora kodu a wazne dla nas nodes mamy pewnie rozpoznane.

> Dlatego twierdzę, że else jest łatwiejsze, bo else można
> ujednoznacznić samą zmianą gramatyki, w dodatku całkiem łatwą.

Z else oczywicie tak tez robie (wystarczy rozbic na dwie produkcje)
Zreszt tak naprawde _co sie tylko_ da wprzegam do gramatyki
rozbijajac pierwotne produkcje ale takze przez jakies mneij elegenckie
sztuczki typu flagi w nodach itp :)

> Język z takim else
> jak w C jest wciąż bezkontekstowy - jedyny kłopot jest tej natury,
> że najprostsza gramatyka bezkontekstowa jest większa niż najprostsza
> gramatyka z niejednoznacznością. Jest większa i zawiera irytujące
> prawie-duplikaty, dlatego literatura woli używać tej drugiej gramatyki,
> gdzie trzeba uważać na sposób potraktowania niejednoznaczności.

Ale w praktyce mnie sprawdza sie zdecydowanie ta pierwsza :)
W praktyce _i tak_ rozbijam wiekszosc bezkontekstowych
produkcji na kilka bo i tak mi sie sprawdza lepiej gdy mam wieksza
odpowioedniosc: produkcja => akcja niz badac w akcji czy aby
jakis nody sa None itp i robic jakis chore switche czy ify :)

> W C++ równolegle z analizą leksykalną oprócz śledzenia typedefów trzeba
> sprawdzać typy, budować hierarchię klas, rozpoznawać miejsca wstawienia
> niejawnych konwersji, rozwiązywać przeciążanie funkcji, dedukować
> parametry szablonów z typów argumentów funkcji szablonowej, uwzględniać
> Koenig lookup, liczyć sizeofy typów, wykonywać arytmetykę na stałych -
> połowa kompilatora musi być napisana w taki sposób, żeby można było
> wykonywać ją przyrostowo na tym, co właśnie sparsowaliśmy, nie znając
> jeszcze pełnego drzewa modułu wychodzącego z parsera.

Swieta prawda :)
Za leniwy jestem aby skonczyc a takiej dzungli :)
Wlasnie ! Z samymi namespaceami wiekszy klopot niz z typedefami
a w polaczeniu jedne z drugimi a jeszcze klasy i templates a jeszcze
to ze szlag wie czy klass czy struct (pol biedy) czy typedef czy enum czy
funkcja  :) Nie no dosc :)
Parser synktatyczny robi sie niechcacy pelnym kombajnem
semantycznym  i sie odechciewa zyc :)

AK