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.