🚀 go-pugleaf

Piotr Sawicki wrote:
> Sebastian Kaliszewski powiada:
> 
>> def z_bledem(err_cont, a, b):
>>    if not a:
>>      err_cont.call(ErrorA())
>>    elif not b:
>>      err_cont.call(ErrorB())
>>
>>
>> def wolanie(err_cont):
>>    callcc cont:
>>      for i in range(10):
>>        z_bledem(cont, random.choice(True, False), 
>>                       random.choice(True, False))
>>    continue error:
>>      if error.type is ErrorA():
>>        obsługa_na_miejscu()
>>      else:
>>         # pozostałe błędy ma obsłużyć wolajacy wolanie
>>         err_cont.call(error)
>>
> 
> Tak to dziwacznie wymyśliłeś, żeby było kalką wyjątków.
> No i nadal nie wiem, gdzie jest ta niejawna globalna kontynuacja.

Nie piszę tu o globalnej kontynuacji. Przy globalnej byłoby jeszcze gorzej:

def z_bledem(a, b):
   if not a:
     err_cont.call(ErrorA())
   elif not b:
     err_cont.call(ErrorB())

itd...
  err_cont nie wiadomo skąd pochodzi, bo nie jest parametrem

> 
>> VS
>>
>>
>> def z_bledem(a, b):
>>    if not a:
>>      raise ErrorA()
>>    elif not b:
>>      raise ErrorB()
>>
>> def wolanie()
>>    try:
>>      for i in range(10):
>>        z_bledem(random.choice(True, False), random.choice(True, False))
>>    except ErrorA as error:
>>      obsługa_na_miejscu()
>>    # pozostałe błędy ma obsłużyć wolajacy wolanie
> 
> VS np.
> 
> def z_bledem(a,b, contA, contB):
>   if not a: continue to contA()
>   elif not b: continue to contB()
> 
> def wolanie():
>   for i in range(10):
>     z_bledem(true/false, true/false, errorAhandler, errorBhandler)


Zapisz cały odpowiadający kod a nie kawałek. skąd pochodzą errorAhandler 
i errorBhandler? Przecież nie z powietrza?


>>>> One mają sens gdy stosowane są do uzyskania rzeczy które w pozostałych 
>>>> językach są kluczowe, tj podstawowe konstrukcje sterujące.
>>> No ale są tam stosowane również przy obsłudze sytuacji wyjątkowych. 
>>> Bezsensownie?
>> Kluczowe jest *również*.
> 
> Kilka postingów temu postawiłeś tezę, że używanie kontynuacji 
> nie ma sensu w językach typowanych dynamicznie.

Nie prawda. Nie postawiłem takiej tezy.

Postawiłem tezę, że w językach dynamicznych w których wszelkie 
podstawowe konstrukcje (wykonanie warunkowe, powtarzanie) są 
zaimplementowane bez opierania się o kontynuacje, kontynuacje nie mają 
sensu do obsługi sytuacji wyjątkowych.

> Jeśli teraz 
> doprecyzowujesz, że tylko w tych z nich, w których kontynuacje 
> nie są częścią języka,

Wcale tak nie doprecyzowuję. Czytasz to co chcesz przeczytać a nie to co 
jest napisane. Piszę, że mają sens jeśli są częścią języka niezbędną dla 
zaimplementowania w nim konstrukcji podstawowych takich jak wykonanie 
warunkowe.

> to wychodzi banalna tautologia
> (i nie wiadomo po co w to w ogóle mieszać dynamizm).

Wychodzi tylko z tego co Ty chciałeś przeczytać a nie z tego co było 
napisane.

> 
>>> To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.
>> Tyle samo mi daje catch(...) -- w obu wypadkach niewiele.
> 
> Da, jeśli obstawimy nim każde wołanie. No to po co w ogóle wyjątki.

Mowa o wiedzy czy coś wypadło z błędem. catch(...) daje równie dobrą 
(raczej równie nędzną) wiedzę. Nie widzę specjalnego sensu rozwarzania 
przypadków zdegenerowanych.

>>>>> w miejscu wywołania funkcji wiem co się stanie po powrocie.
>>>> Tzn albo pójdzie normalnie, albo poleci w stornę sprawdzenia 
>>>> błedu -- tak samo jest przy wyjątkach.
>>> Nie tak samo, bo jest napisane czarno na białym jaka to strona.
>> Jeśli mamy cokolwiek więcej niż jeden ogólny błąd to dokładnie tak samo 
>> nie wiadomo. W dodatku łatwiej zrobić źle i niezauważyć 
> 
> Jeśli podasz za mało argumentów do funkcji (tzn. pominiesz którąś 
> z wyjątkowych kontynuacji), to da się to wyłapać statycznie, 
> a błąd wykonania pojawi się nawet w prawidłowym przypadku.

Praktycznie to samo masz ze specyfikacjami wyjątków z głupiej Javy. Nie 
skompiluje się, jeśli nie ma statycznie zapewnionej (a raczej 
zamarkowanej) obsługi wszystkich błędów.

> 
>>> A z exceptionami hgw gdzie poleci, trzeba sprawdzać cały program.
>> I tak trzeba sprawdzać cały program. I tu i tu.
> 
> W jednym przypadku wystarczy sprawdzić liniowo, jednoprzebiegowo 
> (czy każdy call uwzględnia błędy) - i to wystarczy do pewności,
> że obsługę błędów przewidziano w stu procentach.

Po pierwsze nie wystarczy, co zostało pokazane wyżej. Można sprawdzić 
czy jest tylko (zamarkowana) intencja sprawdzenia błędu (tzn, czy jest 
podpięta jakakolwiek akcja, jakakolwiek to również zupełnie beznsesnowna 
lub w ogóle dziurawa. To samo dają zwykłe statyczne specyfikacje 
wyjątków rodem z Javy.

Po drugie zaś, to to taki kod niby porządny-kontynuacyjny, się fatalnie 
rozwija (do momentu kiedy nie ulegnie degeneracji). Każda zmiana 
dodająca w jednej głupiej funkcji wymaga dodania nowego parametru w 
każdym miejscu wołania i albo dodania go również do funkcji wołającej (i 
zabawę powtarzamy dla każdej funkcji wołającej w której tak zrobimy) 
albo w każdym z takich miejsc trzeba tworzyć nową kontynuację. Efekt 
dąży (degeneruje się) to analogu tego co się spotyka w kodzie Javowym -- 
globalnego catch.

> W drugim przypadku 
> konieczne jest błądzenie po całym kodzie i analiza wszystkim możliwych 
> tras i przeplotów wywołań. Czas rzetelnego sprawdzenia poleciałby
> w kosmos, więc w rzeczywistości robi się to na oko zostawiając dziury.

Jest tak samo jak ze statycznymi specyfikacjami wyjątków. Albo czas 
rzetelnego sprawdzenia leci w kosmos albo i tak jest na oko.

> 
>>> Żeby sprawdzić jaka
>>> będzie obsługa wyjątku trzeba przeczytać zylion miejsc
>>> kodu które mogą wywoływać aktualnie czytany kawałek.
>> To samo przecież, w oczywisty sposób dotyczy użycie kontynuacji. Nawet 
>> jal kontynuację dostaniesz jako parametr, przy każdym wołaniu może to 
>> być kontynuacjia utworzona zupełnie gdzie indziej więc gdzie indziej 
>> prowadząca. Bez sprawdzenia wszysktkuch miejsc wołania i tak nie wiesz.
> 
> Jak ktoś się uprze, to zawsze może napisać program nieczytelnie
> (ale to widać i można poprawić). W przypadku wyjątków nieczytelność 
> rozwiązania jest nieodłączną cechą ich głównej zalety, jaką jest 
> możliwość przeniesienia obsługi błędu poza miejsce wystąpienia. 

Taka sama nieczytelność jest przy kontynuacjach. Lokalnie nie wiesz skąd 
kontynuację dostałeś. Tu tak samo masz "nieodłączną cechę ich głównej 
zalety, jaką jest możliwość przeniesienia obsługi błędu poza miejsce 
wystąpienia."


>>>> BTW. zrobiono w swoim czasie badania co wpływa na liczbę 
>>>> błędów w kodzie programów pisanych w różnych językach. 
>>> Jak znam życie to nie robili eksperymentów tylko pomiary.
>> Robili eksperyment. Ludzie dostali do napisania programy 
>> (w języku który znali), potem te programy starannie sprawdzono 
>> patrząc ile jest błędów.
> 
> No sorry, ale to nie spełnia wymogów naukowego eksperymentu.

Bo?

> Chociażby nie ma mowy o podwójnie ślepej próbie.

LOL! Idź powiedz to jakiemukolwiek socjologowi :)

Podwójnie ślepa próba *nie jest* jedyną metodą naukowego eksperymentu.

Poza tym jak chcesz na powójnie ślepo testować języki?


>>> W szczególności niewykrycie innych korelacji mogło wynikać 
>>> nie z ich braku, a z przyjęcia złych hipotez badawczych.
>> Hipotezą było, że są języki mniej i bardziej błędogenne.
> 
> To nie jest nawet poprawnie zdefiniowane, nie wspominając 
> w ogóle o falsyfikowalności. Można sobie policzyć jakieś 
> korelacje na nielosowej próbce algorytmów, i w zasadzie tyle.
> Nie wiadomo jakich korelacji nie stwierdzono, bo ich nie badano.

Ach tak, ty nie czytałeś ale wiesz...


>>> I to każdy 
>>> poszczególny call, a nie cały obleczony try-catchem blok.
>> Jak ci bardzo na tej wiedzy zależy, to na końcu możesz 
>> mieć catch(...) -- wtedy wiesz, że tędy przeleci.
> 
> Dlatego pisałem, że wyjątki w najlepszym przypadku dadzą taki sam 
> efekt jak inne metody (po rezygnacji z ich kluczowego ficzeru 
> przerzucenia obsługi błędów wzwyż), ale wtedy są zbędną konstrukcją.

Co ma to co tu napisałeś do tego co ja napisałem?

Poza tym, tak samo kluczowym ficzerem obsługi błędów przez kontynuację 
jest przerzucanie obsługi błędów wzwyż.

>>>> Jeśli masz statyczne specyfikacje wyjątków, to albo obsługa 
>>>> jest na końcu funkcji (w catch / except czy jak tam autorzy 
>>>> języka nazwali) albo w sygnaturze funkcji jest jawnie napisane, 
>>>> że leci dalej. 
>>> To akurat nie jest złe - ale to słabsza cecha 
>>> (w sensie matematycznym).
>> No właśnie nie widzę tej "słabszości".
> 
> Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
> do łapania/przerzucania wyjątków rzuca które z nich,

??? Podkręć jasność.

except WyjątekA łapie obiekty klasy WyjątekA a except WyjątekB łapie 
obikety klasy WyjątekB.

> trudniej sprawdzić poprawność takiej obsługi błędów.

Tzn?


>>>> W przypadku kontynuacji albo masz ogólny skok 
>>>> do miejsca gdzieś w ciele funkcji z której wołasz, 
>>>> albo kontynuacja była parametrem 
>>> Albo wskazujesz inny fragment kodu [...]
>> Ale ten fragment kodu jest skądś dany
> 
> Normalnie palcem można pokazać, nie ma musu 
> stosować na upartego metodę exceptionową w innej składni.

Co można palcem pokazać? To, że nawet przekażesz osobno kontynuację dla 
każdego rodzaju błędu (co samo w sobie w szybkim tempie prowadzi do 
zaciemnienia wywołań) to i tak albo utworzyłeś ją sobie w bloku z 
którego wołasz (czyli jest to samo co except czy C++owe catch tylko 
inaczej zapisane) albo dostałeś z zewnątrz (znów to samo co z wyjątkami).


>> albo zrobiłem  go sobie lokalnie (czyli tak jak catch / except) 
>> albo przyszedł z zewnątrz (czyli lokalnei 
>> nie wiem gdzie to dalej poleci).
> 
> Tylko że jak ktoś ma problem z tym, że w programowaniu używa się 
> zmiennych, to lepiej niech zmieni profil. Przecież nie będziesz 
> zarzucał instrukcji print, że nie wiesz co zostanie wydrukowane 
> przez ,,print variableA''. Problem byłby dopiero gdyby bezparametrowy
> secretprint drukował nieoczywistą wartość wyciągniętą gdzieś z szafy
> (dla mnie tak wygląda perl i jego m@giczne #argumenty domy$lne).

Zatem gdzie widzisz różnicę między napisaniem:

funkcja(x, y, z, on_a, on_b)

a funkcja(x, y, z) throws a, b


Pota oczywiście tym, że od razu widać że a, b to błędy powodowane przez 
funkcję a w on_a on_b trzeba szukać w dokumentacji (albo oprzeć się na 
obyczaju nazewniczym).


>> To nie jest kwestia spartaczenia kontynuacji tylko istnienia 
>> globalnych zmiennych. I (złego) nauczenia ludzi by ich 
>> (nad)używali do trzymania kontynuacji.
> 
> No dobra, ale to kwestia używania zmiennych globalnych 
> w ogóle, a nie szczególnego przypadku.

W tym przypadku "kultura języka" promowała takie rozwiązanie. Ale to już 
problem "kultury języka".


>>>> W przypadku wyjątków Każda wołana funkcja też ma swoją sygnaturę -- 
>>>> wystarczy znać tę sygnaturę by wiedzieć jakie wyjątki wypuszcza.
>>> Ale nie kto je łapie.
>> Tak samo jest z kontynuacjami. 
> 
> Nie tak samo, bo od razu wiem że błąd jest obsłużony,

Jak?

> już w tym 
> miejscu. Samo info o rzucaniu wyżej wyjątku mi jeszcze nie mówi,
> czy jest zawsze sensownie złapany, czy ktoś walnął wielki catch
> na wszystko żeby zapuścić daily build i w końcu odebrać dziecko
> z przedszkola. Wiem że odbębnić zawsze się da, ale możliwość
> otoczenia całego kawałka kodu klamrą catch-everything to ułatwia.

W celu odbębnienia wystarczy raz sobie utworzyć kontynuację 
on_general_failure i sobie ją przekazać gdzie jej potrzeba.

W języku dynamicznym jest jeszcze gorzej, bo możesz zamiast kontynuacji 
przekazać jakikolwiek śmieć (choćby None) i statycznie nic nie wiesz. A 
jakiś tam parametr przekazany jako None nie wygląda od razu alarmująco.

M.in. dlatego piszę że obsługa błędów przez kontynuacje w językach 
dynamicznych ma sens mocno wątpliwy. I dlatego odpowiednio ograniczona 
(choć wystarczająca) forma kontynuacji jaką są wyjątki jest w takiej 
sytuacji lepsza, bo trudniej wszystko cwaniacko rozwalić. Podobnie ja 
programowanie strukturalne -- if, while, for z break i continue jest 
krokiem naprzód wobec łysego goto -- choć za pomocą goto daje się 
wyrzebić więcej niż za pomocą powyższych (które są formą ograniczenia 
goto i opakowania go w ramy).

>> kontynuacje zachęcają by je stworzyć, przekazać 
>> gdzie są wymagane a następnie po cichu wyrzucić.
> 
> Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
> A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
> (sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).

W językach dynamicznych sprawdzenie jest przy użyciu.

>> Przy specyfikowaniu wyjątków jest nie gorzej niż przy kontynuacjach -- 
>> czy dodam do funkcji dodatkowy parametr czy dospecyfikuję rzucane 
>> wyjątki to widać/ nie widać partactwo tak samo.
> 
> Nie zgadzam się, po dopisku throws cośtam jeszcze nie wiadomo czy 
> tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
> wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.

No właśnie nie widzę tego na miejscu.

To, że w różnych rzadko używanych językach zwykle nie widzisz takiego 
kodu wynika moim zdaniem *tylko i wyłącznie* z faktu że są właśnie 
rzadko używane, a więc nie są używane przez przeciętną programistyczną 
małpę (małpy, zależnie od prowieniencji, swoją wiedzę kończą na (Visul) 
Basicu, Javie, PHP, Deplhi (oni nie znają Objective Pascala, oni znają 
Delphi), C lub Fortranie).

> 
>> otrzymana z zewnątrz kontynuacja tak samo będzie pasować 
>> do wszystkich razem.
> 
> Taką bzdurę, że każdy błąd ma ten sam handler, to od razu widać.

Tak samo jak brak catchy w kodzie tylko jeden w main.

Jestem praktycznie pewien, że gdyby Haskell zyskał popularność jak C++ 
(popularności Javy nie zyska po za trudny, porównujmy więc z językiem 
też trudnym) to takie kwiatki widywałoby się w kodzie haskellowym na 
każdym kroku.

> 
>>> I które to są te kluczowe różnice w składni i semantyce między 
>>> Erlangiem a innymi funkcyjnymi? Bo dla mnie jest przede wszystkim mniej
>>> czytelny, a plusy widzę głównie w maszynie wirtualnej (czy jak to zwać).
>> Ta wiele rzeczy co ta maszyna wirtualna daje to część semantyki.
>> Głównie w całej zabawie w przesyłanie komunikatów w około którego 
>> wszystko się kręci. I w tym, że mamy "wbitą w semantykę" współbieżność.
> 
> Spawnowanie ~procesów~ i przesyłanie komunikatów jest też gdzie 
> indziej bibliotecznie, tylko bez zapewnienia wszystkich
> bajeranckich cech produkcyjnych erlangowego vm-u. Tychże pozbawiony
> interpreter erlanga napisany samemu byłby już mocno taki sobie.

I owszem i nikt by go nie użył. Ale conajmniej część tych cech 
produkcyjnych łapie się w semantykę. No i w ogóle częścią Erlanga są 
określone np. założenia wydajnościowe (choć można dyskutoweać czy to 
semantyka czy nie -- w każdym razie są języki gdzie np. specyfikuje się 
koszt asymptotyczny określonych operacji).
Podobnie określone założenia (choć zupełnie inne) są niejako częścią np. 
C (bliskość sprzętu, w wielu dziedzinach warunek konieczny).


>>> Lambdy, funkcje wyższych rzędów, częściowa ewaluacja i leniwość 
>>> to cechy w dobrych językach dostępne out of the box, bez żadnego 
>>> metaprogramowania.
>> Ale ja nie mówię o tym. boost::lambda to co innego niż boost::mpl. 
>> boost::mpl daje metefunkcje (biedne i niewygodne ale są).
> 
> To co mpl nazywa metafunkcjami to przecież po prostu funkcje
> wyższych rzędów - gdzie indziej nie robi się takiego rozróżnienia,
> po prostu typ->typ jest równie dobrym typem jak struktura czy unia.

Nnno, pod warunkiem, że typ jest obiektem języka. Metafunkcje też tym 
się też wyróżniają, że są wykonywane w czasie kompilacji i semantyka 
języka to wymusza.


>> W mpl pisze się programy piszące programy.
> 
> Hello world. 

Generalnie tak, ale jak już pisałem, spotykam takich którzy w tym piszą 
zdecudowanie więcej. A przez samą liczbę piszących w C++ może się okazać 
że oni i tak stanowią większość metaprogramujących w ogóle.


>>>> BTW. nigdy nie podobało mi się użycie monad (plus dziwacznych typów 
>>>> reprezentujących stan świata) do uzyskiwania prawie-imperatywizmu. 
>>>> Dla mnie to jest intelektualny hack.
>>> Zamyka efekty uboczne w piaskownicy, niezły wynik.
>> Stawiając płot dookoła sebie zamykam świat za płotem? 
>> Intelektualny hack i tyle :)
> 
> Ja tam lubię sandboksy.

Dla mnie to to jest sandbox wywrócony na lewą stronę :)


>> W szczególności stan świata jest niezdefiniowany (bo i nie ma jak), 
>> jest ukrywany w pseudowartości która wartością nie jest. Nie bardzo 
>> więc można mówić o zbiorze wartości (skoro nie ma wartości), więc 
>> i nie bardzo można mówić o funkcji.
> 
> Chyba tego nie przemyślałeś na poziomie epistemologicznym,
> niepoznawalność to jeszcze nie jest niezdefiniowanie 
> (że już o kryteriach bycia prawdziwą wartością nie wspomnę).

Niepoznawalność to oczywiście nie niezdefiniowanie. Ale tu wg mnie mamy 
właśnie niezdefiniowanie. Wartość niepoznawalna przede wszytskim jest i 
jest niezmienna. Można się nią normalnie posługiwać poza samym 
poznaniem. Świat (stan zewnętrzny) to nie jest wartość w normalnym 
rozumieniu tego słowa, jest np. jednorazowy (nie dziwne nie daje się 
cofnąć ani zatrzymać), itd...

Tzn. typ w którym reprezentuję niepoznawalną stałą Chatina jest dla mnie 
  jak najbardziej normalnym typem, jego wartości mogę przypisywać, 
przekazywać do wywołań, brać jako wyniki, itd. A tu guzik.

> 
>>>> Usiłowanie (niby) czysto funkcyjnej realizacji zadań które 
>>>> nie dają się sprowadzić do podania argumentów przy wywołaniu 
>>>> i poczekania na wynik 
>>> Wszystkie się dają, kwestia czytelności i łatwości napisania.
>> Nie dają się. Istnieją zadanie w których całe clue polega na tym, 
>> że są w nich zależności czasowe.
> 
> Nie bardzo chwytam, masz na myśli zadania real-time?

Nie tylko, ale też. Ogólnie zadania w których pewne akcje zależą od 
wcześniej wykonanych, od wyników (i błędów) występujących wcześniej. W 
dodatku mogą też zależeć od pory dnia/tygodnia/miesiąca/roku. Ot, 
przeciętny program użytkowy typu Word się tu łapie.

> 
>>>> Funcyjność nie jest interaktywna, może być 
>>>> interaktywnie użyta niejako z zewnątrz.
>>> Nie mam pojęcia, co masz na myśli.
>> To, że wykonanie funkcji to przygotowanie argumentów i poczekanie na 
>> wynik. Możesz taką funkcję sobie w różnych miejscach i z różnymi 
>> argumentami wołać i za każdym razem czekać na wynik. 
> 
> Prawdę powiedziawszy nie wiem na ile poważnie piszesz o różnej sile 
> języków turing-kompletnych. Z zastosowań interaktywnych masz przecież 
> funkcyjnie napisany filesystem, serwery sieciowe czy windowmanager.

Pamiętaj, że maszyna Turinga to tylko model. Pewnych rzeczy nie modeluje 
i tyle -- po prostu go nie dotyczą. Funkcyjnie możesz zapisać stan 
wewnętrzny, ale ze stanem zewnętrznym (czas systemowy, zewnętrzne źródło 
danych losowych, etc.) jest gorzej. Albo zamiata się pod dywan tworząc 
pseudowartości których się nie daje traktować jak wartości i udaje że 
wszystko ok, albo po prostu przyznaje się jasno, że coś tam wykracza 
poza model i już. Wolę ten drugi wariant, wolę języki gdzie jest 
napisane: ten kawałek nie jest funkcyjny i już, używamy tak i tak. Ale 
to moja osobista, głównie estetyczna preferencja.

pzdr

\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)