🚀 go-pugleaf

Sebastian Kaliszewski powiada:

>> Przy obsłudze błędów poprzez kontynuacje? Not rili.
>
>Można przez kontynuacje czy insze monady (jedno daje się 
>wyrazić przez drugie). Ale bez odpowiedniego lukru syntaktycznego 
>(albo makr) to zaczyna to słabo wyglądać.

Do każdego mechanizmu języka powinna być przewidziana składnia
(sprawdzić czy nie ksiądz^W Lisp), bez niej słabo zaczyna wyglądać 
nawet deklaracja procedury. A parser to akurat najbardziej banalna 
część kompilatora, niemalże generowana automatycznie z opisu gramatyki.  

>I jaką nową jakość chcesz uzyskać za pomocą obsługi 
>błędów przez kontynuacje? 

Zysk na QA dzięki jawnemu specyfikowaniu przepływu sterowania. 
Stosowanie wyjątków, przy wszystkich zaletach, powoduje że nietrywialne 
staje się statyczne sprawdzenie, czy obsłużono wszystkie rzucane błędy.

> Rzeczywistość jednak jest taka, że to C, Java, C++ i PHP to
> najpopularniejsze języki :)

To empiria, ale możliwych powodów popularności języka jest 
tyle, że sama w sobie nie przesądza ona o jego jakości.

>> Odróżnijmy jednak języki w których wyjątki
>> są elementarną konstrukcją semantyczną od takich, gdzie dodano
>> je jako rozszerzenie albo wręcz umożliwiono korzystanie z nich
>> poprzez biblioteczną implementację normalnymi środkami (Haskell).
>
>Normalnymi czyli za pomocą monad i lukru syntaktycznego.

Jak programujesz w Haskellu bez użycia monad, to wyjątki są na plaster.
Z monadami już jest sens korzystania z wyjątków, ale wtedy są one AFAIK
zaimplementowane zwyczajnymi strukturami z funkcjami wyższych rzędów 
- samemu sobie można taką bibliotekę napisać, to nie element języka.

>Na tej samej zasadzie można się zastanawiać, czy obiektowość należy
>udostępniać jako cechę języka czy też wystarczy dać odpowiednie makra i
>obiektowość zaimplementować w bibliotece (patrz CLOS :) ) 

Zależy od ekspresywności języka oczywiście - ale to Ty chciałeś
oceniać cechę języka na podstawie tego, w ilu językach występuje.
Jeśli ma się liczyć również możliwość bibliotecznego doimplementowania
takiej cechy w elastycznych językach wysokopoziomowych, to tą drogą
rozumowania można uzasadniać dowolnie sensowne konstrukty.

>Przy czym współczesne wersje paru tych języków wyjątki ma.

No i spoko, nie mam nic przeciw wolności wyboru - ale to że dodano
jakiś bajer nie oznacza że bez niego wcześniej nie dało się programować
czegokolwiek poza teoretycznymi zabawami w stylu własnego translatora.

>BTW jesteś pewien, że Smalltalk nie miał od początku? 

Nie rzucę linkiem do pierwotnej definicji, ale w opisach historii
projektowania Smalltalka nie widziałem żadnej wzmianki. Zresztą
do tej pory jest to realizowane zwykłymi obiektami i komunikatami.
Które są tytułowane exception, ale są trochę czym innym (sygnały
z możliwością zrobienia resume albo retry). Nie wymaga to specjalnego
wsparcia języka dla wyjątków, wystarczy że pozwala on na domknięcia.

>> w języku z kontynuacjami. Za to szablony są idiotyczne również
>> przy typowaniu statycznym, ale z kwantyfikatorami lub funktorami.
>
>Nie koniecznie. Oczywiście nie mogą być tak obleśnie 
>zrealizowane jak w C++. 

A znasz jakąś inną? Dla mnie sensem wyodrębnienia terminu template
jest właśnie wskazanie tego konkretnego idiotycznego pomysłu, żeby
wielokrotnie kopiować definicje przeklejając kolejne typy. Genericsów, 
typów polimorficznych czy type_classów już bym nie nazwał szablonem. 

Piotr Sawicki