🚀 go-pugleaf

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

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

Śmieszne. W źródle na pierwszy rzut oka w ogóle nie widać, które są
które. Ten podział jest sztuczny, związany z implementacją, a nie
z tym, co programista chce wyrazić. One są bardzo sensowne, tylko Twój
ulubiony C++ nie umie ich oferować.

Prawda, że część z nich to ciała pętli, więc przy innym języku i innym
stylu programowania byłyby zastąpione bardziej rozwlekłymi konstrukcjami.

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

Nazwy, przez które odwołujemy się do tych obiektów, są lokalne,
bo nie są globalne. Same obiekty nie potrzebują cechy lokalności
na poziomie języka.

> Dostęp do obiektów na zewnątrz funkcji lokalnej mógłby mieć różne
> formy (przez wartość, przez referencję)

Wystarczy tylko przez referencję. Dostęp przez wartość jest
szczególnym przypadkiem dostępu przez referencję, bo to po prostu
dostęp do innego obiektu, do kopii tego pierwszego.

> i być rozwiązywany w różnym czasie (przy definicji funkcji lub przy
> jej aplikacji).

Wystarczy tylko przy definicji. Rozwiązywanie dostępu przy aplikacji
jest szczególnym przypadkiem dostępu przy definicji, kiedy to zmienna,
przez którą odwołujemy się do tego obiektu, implementuje dynamiczne
wiązanie (w Lispie one są nazywane special variables, w innych
językach czasem dynamic variables).

Przy czym w Common Lispie tworzenie nowej zmiennej o leksykalnej
widoczności ma taką samą składnię, jak utworzenie nowego wiązania
zmiennej dynamicznej, co moim zdaniem jest błędem.

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

Poproszę tylko trzecią wersję, resztę sobie z niej sam zrobię w razie
potrzeby.

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

Owszem, bo kiedy był tworzony, część ludzi zajmujących się Lispem
jeszcze nie zdawała sobie sprawy, że to jest zły pomysł na domyślne
zachowanie.

> to właśnie pokazuje, że arbitralny wybór reguł widoczności nie musi
> być tym, co akurat będzie potrzebne.

Oczywiście. Wybór leksykalnego wiązania nie jest arbitralny, tylko
jedynie słuszny. Zwłaszcza że pozwala wyrazić też dynamiczne wiązanie.

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

Z tego, że niektórzy wciąż się łudzą, że w C++ da się to zrobić, nie
wynika, że to prawda. Wymagałoby to zbyt dużego odejścia od założeń C++
(o niszczeniu zmiennych lokalnych) albo niekonsekwentnej semantyki
(wykonywanie kopii zmiennych lokalnych, współdzielenie globalnych)
albo jawnego wypisywania zmiennych wolnych (czyli nie udajemy, że to
są te same zmienne, tylko wymyślamy lukier składniowy na function
objects).

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

Co to znaczy "potrzebne"? Nie jest niezbędne. Jest przydatne.
Jak to zwykle z konstrukcjami językowymi bywa.

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

Ok, prawie żaden.

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

I te języki powinny pozostać do specjalizowanych zastosowań: mocno
ograniczonych zasobów i hard real time wymagań, kiedy nie możemy sobie
pozwolić na luksusy wygodnych konstrukcji, tylko musimy pilnować
zasobów zużywanych przez każdą operację.

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