🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>>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.

OK. Jak już pisałem wcześniej - mogę to związać z pojęciem zakresu pętli 
i widoczności obiektów. Jeśli w jakimkolwiek miejscu widzę obiekty 
zadeklarowane w pętli, to mogę tą pętlę też przerwać. To właśnie 
obejmuje nie tylko ciąg instrukcji traktowany jako sekwencję, ale 
również lokalne rozgałęzienia w rodzaju instrukcji warunkowych (tak 
naprawdę to dopiero wtedy przerywanie pętli ma sens).

Wywołanie funkcji w pętli powoduje, że powstaje nowy zakres, gdzie 
obiekty stworzone w pętli nie są widoczne (to też zależy od języka, ale 
mówię o "moich" językach, gdzie widoczność jest ustalana statycznie) - 
wtedy nie pozwalam też na przerwanie pętli. Jedno i drugie wchodzi w 
skład tematu, który nazwałbym: "widzę, gdzie jestem".
Nie przerywam pętli, której nie widzę.

> 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.

Ja też jestem zdumiony, na ilu frontach można spieprzyć język 
programowania. Nie interesuje mnie ten przykład. Bardziej mnie 
interesują języki, w których taka gimnastyka nie występuje - bo albo w 
ogóle nie ma break (jak w "Twoich" językach) albo nie ma finally (jak w 
"moich").

>>>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

Sorry, nie zrozumiałem, o czym mówisz. Jeżeli pod pojęciem "głębszego 
wnętrza ciała pętli" rozumiesz "jakieś miejsce, gdzie ciągle widać 
pętlę", to oczywiście przerwania pętli powinno być możliwe i nadal jest 
jej logiczną częścią.


>>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.

No właśnie nie jest przezroczyste, bo powstaje kod, który nie widzi 
pętli, którą przerywa. Taki kod (czyli tą funkcję) można wywołać w inny 
sposób, i wtedy przestaje mieć sens. Staje się niejawnie związany z 
pętlą, z której jest wywoływany i ten niejawny związek sprawia, że kod 
jest trudniejszy w utrzymaniu. Fakt, że token to poprawia.
Jeżeli natomiast mówisz o funkcji nienazwanej, której nie da się wywołać 
inaczej niż w tym miejscu, gdzie została zdefiniowana "w locie" 
(lambda), to ten problem znika, ale nadal będę twierdził, że jest to 
niepotrzebnie ciasny model. Zamiast mówić, że ciało pętli jest lokalnie 
zdefiniowaną i zaaplikowaną funkcją, wolę powiedzieć, że ciało pętli 
jest składniową częścią pętli i ma do dyspozycji dedykowane mechanizmy 
jej przerwania, wznowienia, czy co tam jeszcze może być potrzebne.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/