🚀 go-pugleaf

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.

> 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)
  
>>> 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. Jeśli teraz 
doprecyzowujesz, że tylko w tych z nich, w których kontynuacje 
nie są częścią języka, to wychodzi banalna tautologia
(i nie wiadomo po co w to w ogóle mieszać dynamizm).

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

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

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

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

>>> 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.
Chociażby nie ma mowy o podwójnie ślepej próbie.

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

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

>>> 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,
trudniej sprawdzić poprawność takiej obsługi błędów.

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

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

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

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

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

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

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

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

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

Hello world. 

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

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

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

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


Piotr Sawicki