🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>Chodzi mi o to, że dostęp z funkcji lokalnych do ich zewnętrznego
>>zakresu *nie jest* (albo nie musi być) integralną częścią koncepcji
>>funkcji lokalnych.
> 
> Dla mnie jest.
> 
> Poza tymi 408 anonimowymi funkcjami używającymi lokalnego środowiska
> są 1004, które go nie używają i zostały przez kompilator wyniesione
> na toplevel i zaalokowane statycznie. Bywa tak i tak, a Ty uwzględniasz
> tylko tę łatwiejszą część.

Bo tylko ta część ma dla mnie sens.

>># the name space is not polluted with the names of entities that are
>>supposed to be used only once
>># the "locality of reference" in the source code is higher
>># the code is potentially shorter and more expressive
> 
> To są powody, żeby używać funkcji lokalnych zamiast globalnych.
> Nie są to powody, żeby zabierać tym funkcjom dostęp do lokalnego
> środowiska.

Przecież ich tak nie przedstawiam. Powody, dla których zabroniłbym 
takiego dostępu są inne.

> Owszem, w C++ nie ma jak technicznie dać im tego dostępu, ale to
> problem C++, nie mój.  C++ samo się na to skazało przez nieuwzględnienie
> odśmiecania i przez przymusowe niszczenie obiektów zawartych w zmiennych
> lokalnych, nawet jeśli będą jeszcze potrzebne.

Jeśli będą jeszcze potrzebne, to znaczy, że nie są lokalne. I to jest 
właśnie powód, dla którego nie mieszałbym pojęcia obiektu lokalnego i 
jego nielokalnego wykorzystania.
Dostęp do obiektów na zewnątrz funkcji lokalnej mógłby mieć różne formy 
(przez wartość, przez referencję) i być rozwiązywany w różnym czasie 
(przy definicji funkcji lub przy jej aplikacji). Już takie pobieżne 
rozpatrzenie tematu daje 3 sensowne możliwości (wartość/kopia ewaluowana 
w czasie definicji, wartość/kopia ewaluowana w czasie aplikacji, 
referencja). *Gdybym* chciał mieć taki dostęp, to dla każdego z tych 
trzech wskazałbym przykład, gdzie byłoby to "fajne" i gdzie ma sens.
I dla każdego z tych trzech potrzebowałbym różnej składni, żeby je 
rozróżnić.
I nowy Perl gotowy.

(Popraw mnie, jeśli się mylę. Z tego co zauważyłem, to Emacs Lisp 
odwołuje się do zmiennych z zewnętrznego zakresu w czasie aplikacji 
lambdy a nie w czasie jej definiowania. Chciałem w jednej procedurze 
stworzyć keymapę z lambdą tak, aby była dostępna później - niestety, 
wtedy już nie ma tych zmiennych, które istniały w czasie definiowania 
lambdy. Żeby wymusić ewaluację zmiennej w czasie definiowania lambdy a 
nie w czasie jej aplikacji, musiałem posklejać całość z konstrukcji typu 
(list 'lambda ...) - to właśnie pokazuje, że arbitralny wybór reguł 
widoczności nie musi być tym, co akurat będzie potrzebne. Chyba każde 
rozwiązanie prowadzi do nowego Perla.)

> W modelu C++ można sobie wyobrazić tylko półśrodek: tzw. downward
> closures

To słabą masz wyobraźnię. Ten temat był wałkowany kilka razy na 
comp.lang.c++.moderated. Paru ludzi miało ciekawe pomysły na ogólną 
implementację tego tematu.
Pytanie, czy to jest potrzebne. Nie w sensie teoretycznym (czyli: mamy 
paru gości, którzy się świetnie bawią i piszą na ten temat artykuły), 
ale praktycznym (czyli: używamy tego w realnych projektach, z realnymi 
procesami i standardami kodowania).

> Model C++ jest zakonserwowany w C++, a poza tym martwy: żaden
> projektant innego języka go nie wybiera dla nowych projektów.
> I bardzo dobrze.

(błąd logiczny - nie jesteś w stanie udowodnić tego, że "żaden 
projektant...", natomiast wskazanie co najmniej jednego projektanta, 
który tak właśnie robi, jest trywialne - również przez ogłoszenie, że 
samemu się właśnie zaczęło to robić)

Ada ma taki sam model. Co najważniejsze - zarówno Ada jak i C++ były 
tworzone w czasie, gdy "Twój" model był już znany (również GC, itp.). 
Czyli brak tych ficzerów to nie jest kwestia anachroniczności danych 
języków, ale raczej świadomych wyborów. Inna sprawa, że cele 
projektantów też ulegają ewolucji i np. dzisiaj jest duża presja na 
wprowadzenie GC do C++ (Ada i tak ma opcję GC, z której korzystają 
kompilatory produkujące kod dla... JVM, ale lambdy tam nie ma i nie 
będzie). Co z tego będzie? Nie wiem.


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