Dnia Tue, 08 May 2012 16:10:51 +0200, zażółcony napisal:

> W dniu 2012-05-04 00:51, M.M. pisze:
>> <f...@g...SKASUJ-TO.pl> napisał(a):
>>
>>>>
>>>> http://www.tckerrigan.com/Chess/TSCP
>>>>
>>>
>>> no to jest dosyc ciekawe (ciekawe jest np hall of
>>> shame ) to co by mi sie gigantycznie przydalo to
>>> cos takiego tylko nie dotyczacego programu szachowego
>>> a minimalnego kompilatora c (najlepiej z jakims ciezkim
>>> komentarzem albo wewn tutorialem zeby dalo sie to
>>> jakos latwo przeczytac)
>>
>> Trudno przecenić wartość edukacyjną minimalnych programów i
>> prostych przykładów. Osobiście sporo się nauczyłem właśnie
>> na źródłach TSCP. Dzięki temu mogłem czytać źródła bardziej
>> zaawansowanych programów. Jeśli chciałbyś się zainteresować
>> budową kompilatorów to pewnie rozpoczęcie nauki od czytania
>> najprostszych źródeł byłoby również dobrą lekcją. Ale język
>> C, nie wspominając o C++ to dość duże bydle. Może warto
>> poszukać jakiegoś kompilatora/parsera również dla minimalnego
>> języka?
>
> Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
> + warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
> przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
> uporządkowany. Prowadzą jak po sznurku.
>
> Najpierw scanner, potem na to jakiś YACC a potem... Imo ważna
> jest kolejność wchodzenia w temat, np. sam fakt rozdzielenia
> scannera od parsera to pierwszy kroczek do przodu. Potem stopniowe
> dodanie do tego kompilacji do jakiegoś kodu pośredniego itp itd.

... na tym poziomie to można znaleźć to samo na pierwszym lepszym wiki
o kompilatorach. Niektóre parsery BTW są tożsame ze scannerem,
pytanie czy wykładowca uaktualnił skrypt po dwutysięcznym którymś.

>
> Analiza programów bez jakiejkolwiek wiedzy teoretycznej
> (np. co to jest alfabet, jakie są rodzaje gramatyk i pułapkach
> niejednoznaczności, sposoby rozbioru) wydaje mi się jednak
> podejściem koszmarnie nieefektywnym i rokującym z dużym
> prawdopodobieństwem załamanie/porzucenie
> tematu :)

Czasem można mieć podejście takie jak kompilator: czytać
sobie kod i oglądać jak jest napisany, a (prawie jak kompilator)
olewać co on robi na jakimś poziomie. Chociaż jeżeli mam być
szczery to nieczęsto mam takie zapędy, ale poprawiając wielki
blob którego nie znam to tak faktycznie działa, nie muszę
znać całości żeby go odpowiednio przekształcić: robi potem to
samo, tylko szybciej i się nie wywala, a analizuję go
bardzo wybiórczo (a'la escape analysis). Oczywiście tak jest
wtedy, gdy muszę poprawić coś, co mam centralnie w dupie,
poza tym że ma działać potem lepiej.

Uprzedzając: znam teorię.

Edek