🚀 go-pugleaf

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

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

Zgodnie z tym kryterium powinno też obejmować lokalne funkcje.
I u mnie obejmuje, a u Ciebie nie.

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

A ja mówię o moim, gdzie jest ustalana statycznie *i* obejmuje obiekty
zdefiniowane w pętli.

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

Musi być coś zamiast finally, żeby język był praktyczny. Common Lisp
ma unwind-protect, C++ ma destruktory zmiennych lokalnych, C# ma using.

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

Ależ widzi. Tyle że jeśli się uprzeć, to można zbudować kod, który
będzie próbował przerwać pętlę po tym, jak ona się już zakończyła.
Takie życie.

Sytuacja jest podobna do próby operacji na pliku po jego zamknięciu.
Efekt też. Nie jest to jednak powód, żeby zabronić przekazywania
uchwytów do plików między funkcjami, mimo że zabronienie tego
(i automatyczne zamykanie pliku na końcu funkcji, która go otworzyła)
rozwiązałoby problem operacji na zamkniętych plikach.

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