Witam,

Na tej grupie wiele było dyskusji na temat narzedzi
do tworzenia parserow na bazie gramatyk formalnych.

Mam pytanie, ktory z jezykow o niemarginalnej
popularnosci uzywa takich tooli do wsparcia kompilatora
tudziez interpretera? Jesli zaden popularny tego nie robi,
to jakie sa przeciw stosowaniu tooli w takich sytuacjach,
czyli czemu uzytkowe jezyki nie chca uzywac tooli?
Jesli ktorys jezyk uzywa toola, to ktory. Jaka ma gramatyke
i jaki tool jest w uzyciu?

Pozdrawiam,
Seweryn Habdank-Wojewódzki.

do góry

Użytkownik Seweryn Habdank-Wojewódzki napisał:
> Mam pytanie, ktory z jezykow o niemarginalnej
> popularnosci uzywa takich tooli do wsparcia kompilatora
> tudziez interpretera? Jesli zaden popularny tego nie robi,

GCC do wersji 3.4 używało YACC. Od 3.4 ma ręcznie napisany parser.
Wyrzucenie YACC przyspieszyło pewnie to, że jest to generator
gramatyk LALR(1) i nie bardzo nadaje się do złożonych gramatyk
jak C++. Poniższy link opisuje m.in. problemy z generatorami
LALR dla C++:
http://scottmcpeak.com/elkhound/elkhound.ps

Innym przykładem jest Ocaml, który używa wersji YACC dla tego języka.

> to jakie sa przeciw stosowaniu tooli w takich sytuacjach,
> czyli czemu uzytkowe jezyki nie chca uzywac tooli?

Ręcznie pisanie parserów umożliwia większą kontrolę nad całym
procesem i co za tym idzie lepszą możliwość informacje o błędach i
lepszą możliwość reakcji na błędy, itp. Jeżeli podejdzie się do tego
starannie, efekt jest świetny o czym w odnośniku poniżej (część
przykładów jest wynikiem lepszej semantyki, a nie parsera):
http://blog.llvm.org/2010/04/amazing-feats-of-clang-
error-recovery.html

Generatory parserów umożliwiają szybsze napisanie gramatyki. Oczywiście
jest mniejsza elastyczność jeżeli chodzi o reakcję na błędy, ale przy
odpowiednim podejściu efekt też może być zadowalający:
http://research.swtch.com/2010/01/generating-good-sy
ntax-errors.html

Pozdrawiam
KK

do góry

Krzysiek Kowaliczek pisze:
> Użytkownik Seweryn Habdank-Wojewódzki napisał:

>> to jakie sa przeciw stosowaniu tooli w takich sytuacjach,
>> czyli czemu uzytkowe jezyki nie chca uzywac tooli?
>
> Ręcznie pisanie parserów umożliwia większą kontrolę nad całym
> procesem i co za tym idzie lepszą możliwość informacje o błędach i
> lepszą możliwość reakcji na błędy, itp. Jeżeli podejdzie się do tego
> starannie, efekt jest świetny o czym w odnośniku poniżej (część
> przykładów jest wynikiem lepszej semantyki, a nie parsera):
> http://blog.llvm.org/2010/04/amazing-feats-of-clang-
error-recovery.html
>
> Generatory parserów umożliwiają szybsze napisanie gramatyki. Oczywiście
> jest mniejsza elastyczność jeżeli chodzi o reakcję na błędy, ale przy
> odpowiednim podejściu efekt też może być zadowalający:
> http://research.swtch.com/2010/01/generating-good-sy
ntax-errors.html


Wiesz coooooo, i tak i nie. W automatycznym będzie reakcja na błąd
zawsze podobna, w ręcznym może i tu i ówdzie lepsza, ale nierówna.

Mój Ulubiony Konpilator C++ (tm) ma jak się wydaje ręczną. Czasem to
cholernie rozpaczliwy patch na sensowny starszy kod. (Oczywiście nie
widzialem źródel kompilatora, odbieram po efektach)

Gdy kod jest duży, obiektówka przekracza złożonością wyklikiwany kod
VCL, duży projeky, ma koszmarne fałszywe komunikaty o błędach. Po
zwaleniu specyfikacji jakiejś metody (ok!) pięcet linii dalej czepia
się na oślep, stosunkowo często wbudowanych typów TDateTime i podobnych
(????), oraz wnętrze stringów przestaje mu się podobać.
Po poprawienie pierwszego błędu, następne znikają.
Stąd wnioskuję, że ktoś to w przypływie rozpaczy przed odbiorem ostro
ręcznie patchował.
Same typy wbudowane (mocny rodowód pascalowy), nie są naturalnie
kompilowane, są na to blade wzmianki w helpach, ale raczej stwierdzam na
nos uzytkownika.

Wolę automatyczną diagnostykę np. z Antlr, może nie jest jak idealny
ręczny kompilator programistów którzy się nie śpieszyli, ale całkiem
sensowna.

do góry

Użytkownik Jacek Czerwinski napisał:
> Wiesz coooooo, i tak i nie. W automatycznym będzie reakcja na błąd
> zawsze podobna, w ręcznym może i tu i ówdzie lepsza, ale nierówna.
[...]
> Wolę automatyczną diagnostykę np. z Antlr, może nie jest jak idealny
> ręczny kompilator programistów którzy się nie śpieszyli, ale całkiem
> sensowna.

Jak napisałem ręczne pisanie parserów daje większe możliwości, ale
trzeba się do tego porządnie przyłożyć. Jak chce się coś zrobić szybko
to lepiej użyć generatora. Sam jakiś miesiąc temu napisałem parser
jednego z języków opisu sprzętu ( SystemVerilog ). Gramatykę ma pogiętą
prawie jak C++. Całość popełniłem w ANTLR. Po ok 8 dniach ( gramatyka
jest niedeterministyczna ) miałem gotowy, szybko działający parser.
Napisanie tego ręcznie zajęłoby dużo, dużo więcej czasu i przy okazji
popełniłbym sporo błędów ( i z całą pewnością oszalał biorą pod uwagę
jak pogięta gramatykę ma ten język ).

Pozdrawiam
KK

do góry

Dnia 09.04.2010 Krzysiek Kowaliczek <k...@g...com>
napisał/a:

> Innym przykładem jest Ocaml, który używa wersji YACC dla tego języka.

Ja bym nie nazwał ocamlyacc "wersją yacc". Te dwa narzędzia zupełnie różnią
się pod względem komfortu używania i generowanego kodu, więc mają się do siebie
powiedzmy jak krzesło do krzesła elektrycznego :)

--Daniel

do góry

Użytkownik Daniel Janus napisał:
> Ja bym nie nazwał ocamlyacc "wersją yacc". Te dwa narzędzia
zupełnie różnią
> się pod względem komfortu używania i generowanego kodu, więc mają się do siebie
> powiedzmy jak krzesło do krzesła elektrycznego :)

Ocamlyacc samą nazwą nawiązuje do YACC. Oba generatory są typu LALR(1)
( YACC dodatkowo ma GLR ). Używają tej samej składni. Jeżeli chodzi o
implementacje gramatyki to nie ma żadnej różnicy, t.j. tak samo trzeba
walczyć z konfliktami w jednym jak i drugim. Ocamlyacc ma przyjemniejszy
interfejs, no i sam Ocaml ma algebraiczne typy danych.

Pozdrawiam
KK

do góry