-
Data: 2010-04-09 12:04:26
Temat: Re: Gramatyki jezykow, ich kompilatory/interpretery i toole
Od: Jacek Czerwinski <...@...z.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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.
Następne wpisy z tego wątku
- 09.04.10 12:36 Krzysiek Kowaliczek
- 09.04.10 14:36 Daniel Janus
- 09.04.10 14:54 Krzysiek Kowaliczek
Najnowsze wątki z tej grupy
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-06-27 Re: Prywatny parking? Pierwsze 10 minut bezplatnie
- 2024-06-27 A co mnie to koooorwa obchodzi?
- 2024-06-28 nawigacja satelitarna
- 2024-06-28 SmartLife/Tuya i osuszanie -- mordowanie z zimną krwią...
- 2024-06-27 położyłem kafelki
- 2024-06-28 Łódź => International Freight Forwarder <=
- 2024-06-28 Łódź => Spedytor Międzynarodowy <=
- 2024-06-28 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-06-28 Sopot => Team Leader E-Commerce for Foreign Markets <=
- 2024-06-28 Warszawa => Senior React Native Developer <=
- 2024-06-28 Warszawa => Frontend Developer (React) <=
- 2024-06-28 Warszawa => Software .Net Developer <=
- 2024-06-28 Warszawa => Frontend Developer (React) <=
- 2024-06-28 Warszawa => Programista Full Stack .Net <=
- 2024-06-28 Warszawa => Frontend Developer (React) <=