🚀 go-pugleaf

Maciej Sobczak <no.spam@no.spam.com> writes:

>> Ta gramatyka w brutalny sposób sięga do wnętrza ciała pętli,
>> tak samo jak goto.
>
> Nie widzę tu brutalności. Nie traktuję ciała pętli jak czarnej
> skrzynki, tylko jak ciąg instrukcji.

Nie jako ciąg instrukcji, tylko jako drzewo ze wszystkimi rodzajami
zagnieżdżonych instrukcji. Wyskoczenie z pętli może się odbyć
z miejsca dowolnie zagłębionego w tym drzewie, a nie tylko między
instrukcjami ciągu.

Czy wykonują się try...finally przerwane przez takie wyskoczenie?
W Javie tak. Efekt tej intrakcji trzeba było osobno zaprojektować,
on nie wynika sam przez się z semantyki poszczególnych konstrukcji.
Gdyby try...finally definiować przez try łapiące wyjątki, to prawie
by działało, ale przy tej interakcji efekt byłby inny, bo try łapiące
wyjątki w Javie nie złapie return ani break, a try...finally owszem.

>> Jeśli pozwolić na przerywanie pętli również z głębszego wnętrza
>> ciała pętli
>
> To mamy sieczkę. Nie widzę powodu, dla którego należałoby takie coś
> uprawiać.

Przecież o ile już zwykły break na to pozwala (jeśli tylko między
szczytem pętli a miejscem wyskoczenia nie ma innej pętli ani switcha),
o tyle break z etykietą służy przede wszystkim właśnie do tego.
Do wyskoczenia bezpośrednio z poziomu ciągu instrukcji będącego
ciałem pętli wystarcza zwykły break bez etykiety.

> Można użyć, ale nie zgadzam się z tym, że jest to kompleksowe
> załatwienie czegokolwiek. Kod, który przestaje być ciałem pętli a
> zaczyna być funkcją, staje się oderwany od pojęć związanych z pętlą
> i nie powinien posługiwać się czymś takim, jak przerwanie pętli.

Nie zgadzam się, że staje się oderwany od pojęć związanych z pętlą.
Funkcja to po prostu sposób na umieszczenie kawałka kodu w jednym
miejscu i użycie go w kilku miejscach, podobnie jak zwykła zmienna to
sposób na użycie jednej wartości w kilku miejscach. Przemieszczenie
wyrażenia do funkcji i aplikacja tej funkcji zamiast wpisania tego
wyrażenia żywcem jest przezroczyste względem wszelkich konstrukcji
użytych w wyrażeniu, również jeśli one wyskakują z pętli.

> Czy język wspiera tą konwencję w jakiś sposób? Po czym poznajesz,
> że rzucono właśnie ten "bilet powrotny" a nie coś innego?

Lokalnie w źródle programu: po tym, że użyto funkcji Escape, a nie
jakiejś innej.

W generycznych konstrukcjach łapiących wyjątki: to ich nie powinno
obchodzić, bo wszystkie wyjątki dla nich nieprzeznaczone powinny
traktować tak samo. Jeśli bardzo chcą, to mogą to poznać po tym,
że to jest wyjątek typu ESCAPE_TOKEN, a nie jakiegoś innego.

> Jeżeli używasz jednego mechanizmu na dwa różne sposoby (w sensie
> konwencji, układu kodu, itp.), to w czym to jest lepsze od dwóch
> dedykowanych mechanizmów?

W tym, że z punktu widzenia mojego odpowiednika try...finally oba
mechanizmy załatwia się tak samo. To samo dotyczy wszelkich innych
konstrukcji, które łapią wszystkie wyjątki i obsługują je w generyczny
sposób.

Na przykład konstrukcja "wykonaj dany kod z timeoutem - jeśli czas się
skończy, to przerwij" nie przeszkadza w przerywaniu pętli z wnętrza
tej konstrukcji i wiszący timeout będzie poprawnie anulowany, jeśli
kod skończy się przed czasem wyskokiem z pętli.

Inny przykład: sygnały (zarówno uniksowe, jak i używane wewnętrznie,
podobne do wyjątków, tylko asynchroniczne). Lokalnie (w pętli)
ustanowiona funkcja obsługi sygnału może wprost przerwać pętlę!
C zna tylko globalne funkcje obsługi sygnałów, ja się tak nie
ograniczam.

> Rozumiem też, że tworzysz ten "token" niezależnie od tego, czy pętla
> będzie przerwana, czy nie (bo nie wiesz tego przed jej wykonaniem).
> Czyli w przypadku gdy nie było konieczności przerwania pętli, to
> stworzyłeś sobie bez potrzeby jakiś obiekt, który w ogóle nie był
> wykorzystany.

Owszem. Nie przejmuję się tym, mój język i tak ma sporo różnych
narzutów. Z drugiej strony, alokacja obiektu albo nawet grupy obiektów
jest tania (zwykle 5 instrukcji maszynowych).

Jeśli przerwanie pętli jest w głównym ciągu instrukcji, to nie trzeba
stosować Escape - można po prostu warunkowo kontynuować pętlę, bez
żadnych wyjątków. Escape jest potrzebne tylko kiedy miejsce przerwania
pętli jest oddalone od samej pętli.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/