🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>Przerywanie pętli jest wtedy częścią "gramatyki" tej pętli, podobnie
>>jak obecnie samo 'break' - to tylko nadzbiór tej koncepcji.
> 
> 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. Jeżeli pętlę potraktujemy jako coś, co ma 
własny zakres (i np. może deklarować obiekty lokalne), to dopóki jesteś 
w tym zakresie, to możesz przerwać pętlę.

> Niektórzy (Knuth?) proponowali pętlę z wieloma punktami wyjścia,
> niekoniecznie na początku i na końcu. One były zawsze na "wierzchu"
> ciała pętli, wykonywane tylko w zależności od warunku logicznego.
> Semantyka takiej pętli nie sięga do wnętrza innych instrukcji,
> traktuje je jako czarne skrzynki. To jest najczystsza semantycznie
> wersja przerywania pętli.

Mi się podoba - cała logika pętli - *łącznie* z jej przerwaniami - jest 
na jednym poziomie w kodzie.

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

> to albo robimy to przez wzbogacenie semantyki wybranych
> konstrukcji [...] albo załatwiamy sprawę kompleksowo: używamy już
> istniejącego mechanizmu wyjątków.

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.

Twoja argumentacja jest wynikiem tego, że przyjąłeś pewien ciasny 
schemat patrzenia na program. Wyjątki do przerwania pętli mogą być 
najlepsze w Twoim ciasnym schemacie, ale nie są takie w innych językach, 
które na różne koncepcje oferują dedykowane konstrukcje i pozwalają 
dzięki temu jawnie wyrazić w kodzie to, co chce się osiągnąć.

> Drugie rozwiązanie ma tę zaletę, że są tylko dwa możliwe zakończenia
> obliczenia wyrażenia czy wykonania instrukcji: przez zwrócenie wyniku
> albo rzucenie wyjątku.

I to jest właśnie ten efekt - jeżeli traktujesz każdy element programu 
jako coś, co produkuje jakiś wynik, to Twoja argumentacja jest słuszna.
Ale są języki, w których program składa się również z czynności a nie 
tylko z wyrażeń.

> Jak mówiłem, przerwanie pętli moim sposobem wymaga dostępu do
> wartości, którą uzyskuje się w miejscu, do którego sterowanie dochodzi
> po przerwaniu (na zewnątrz pętli).

Czyli robisz sobie z wyjątku taki "token" albo "bilet powrotny".
Tylko że nie widzę tu niczego, co by pasowało do słowa "wymaga". To jest 
*konwencja* ("patrzcie, jeśli tak właśnie wykorzystuję wyjątek, to mam 
na myśli przerwanie pętli"), ale nie kompleksowe rozwiązanie. 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? 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?

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.
Etykiety pętli nie wymagają tworzenia żadnego obiektu i w tym kontekście 
są całkowicie darmowe.


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