Má Haskell budoucnost?

[v]

Jak (a zda) to skonci zalezi na tom, zda je jazyk liny nebo ne.

Ty výrazy mají přesně definovanou hodnotu a jakým způsobem se na ni převedou (jestli korektně nebo nekorektně) je jenom o implementaci, ne o jazyku. To je to, co říkal zboj.

Pokud by se program na těch výrazech zasekl, tak ten jazyk nesplňuje referenční transparentnost, což je definiční znak pure jazyka.

[Reklama]

[Ondra Satai Nekola]

Ne.

Co ne? Není venku slunečno? Souhlasím

take(3,[1..])
ma jinou hodnotu podle toho, jaky mas jazyk. Muze to byt [1,2,3] nebo ⊥

[Mirek Prýmek]

take(3,[1..])
ma jinou hodnotu podle toho, jaky mas jazyk. Muze to byt [1,2,3] nebo ⊥

Ok, beru. Jistě můžu mít jazyk s libovolně nesmyslnou sémantikou. Třeba takovou, že 1+1 = ⊥ nebo take(3,[1..]) = ⊥. Takže formálně máš pravdu, uznávám. Bavíme se ale o tom, jestli by takový jazyk mělo smysl vytvářet. Já říkám, že si nedovedu moc představit, k čemu by bylo dobré mít pure jazyk bez línosti.

Jaký význam má pojem "nelínost" u pure jazyka? Že se občas zacyklí na něčem, na čem by se zacyklit nemusel? Vlastnost líný/nelíný prostě zásadně ovlivňuje chování u ne-pure jazyků, ale u pure jazyků nemá na nic vliv (kromě tohodle případu, kde je jenom na škodu).

U ne-pure jazyků totiž výraz musím vyhodnotit pokaždé, kdy mě zajímá jeho hodnota. U pure jazyka mi stačí ho vyhodnotit jednou. Proto je mi celkem jedno, kdy to udělám. V principu bych tu tvoji sémantiku mohl korektně naplnit i tak, že si předem zjistím, že se program nutně dostane k vyhodnocování take(3,[1..]), takže se na celý program vykašlu a hned spustím "for( ; ; ) ;"

[Ondra Satai Nekola]

take(3,[1..])
ma jinou hodnotu podle toho, jaky mas jazyk. Muze to byt [1,2,3] nebo ⊥

Ok, beru. Jistě můžu mít jazyk s libovolně nesmyslnou sémantikou.

To je naprosto normalni semantika striktniho jazyka.

Jaký význam má pojem "nelínost" u pure jazyka? Že se občas zacyklí na něčem, na čem by se zacyklit nemusel?

Spotreba pameti. Dokud nedojde na ⊥, tak se u striktnich jazyku lepe resi pametova narocnost.

[andy]

Kód: [Vybrat]

Zde máte příklad z Haskellu: (bohužel na GitHubu jsem nenarazil na reálnou aplikaci, jen školometské příklady)

zipWith' :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith' _ [] _ = []
zipWith' _ _ [] = []
zipWith' f (x:xs) (y:ys) = f x y : zipWith' f xs ys

Při jeho analýze setrváváte neustále ve fonologické smyčce. Detailněji viz zde https://cs.wikipedia.org/wiki/Baddeleyho_model_pracovn%C3%AD_pam%C4%9Bti


Co na tom příkladu není jasné? Jaká smyčka?

[Reklama]

[zboj]

take(3,[1..])
ma jinou hodnotu podle toho, jaky mas jazyk. Muze to byt [1,2,3] nebo ⊥

Ok, beru. Jistě můžu mít jazyk s libovolně nesmyslnou sémantikou. Třeba takovou, že 1+1 = ⊥ nebo take(3,[1..]) = ⊥. Takže formálně máš pravdu, uznávám. Bavíme se ale o tom, jestli by takový jazyk mělo smysl vytvářet. Já říkám, že si nedovedu moc představit, k čemu by bylo dobré mít pure jazyk bez línosti.

Jaký význam má pojem "nelínost" u pure jazyka? Že se občas zacyklí na něčem, na čem by se zacyklit nemusel? Vlastnost líný/nelíný prostě zásadně ovlivňuje chování u ne-pure jazyků, ale u pure jazyků nemá na nic vliv (kromě tohodle případu, kde je jenom na škodu).

U ne-pure jazyků totiž výraz musím vyhodnotit pokaždé, kdy mě zajímá jeho hodnota. U pure jazyka mi stačí ho vyhodnotit jednou. Proto je mi celkem jedno, kdy to udělám. V principu bych tu tvoji sémantiku mohl korektně naplnit i tak, že si předem zjistím, že se program nutně dostane k vyhodnocování take(3,[1..]), takže se na celý program vykašlu a hned spustím "for( ; ; ) ;"

Různé sémantiky pro symbolický systém jsou probémem obecně a nejen v CS, viz např. formální logika a různé sémantiky pro různé dedukční systémy nebo teorie množin a její různé modely (např. ten Gödelův). V IT je to jen názornější, protože na rozdíl od matematických teorií se programy výpočetně vyhodnocují, takže si člověk - když napíše něco blbě nebo si není vědom sématického problému - rychle nabije čumák. Nejhezčí příklad, o němž vím, je v Prologu SLD rezoluce vs. SLG, v té druhé se žádný program nikdy nezacyklí, kdežto v té první je problémem jakákoliv levá rekurze, např. něco jako borders(X, Y) :- borders(Y, X). Čili nemá moc smysl se tu o tom dále hádat, neboť problém je trochu jinde.

[Ondra Satai Nekola]

(Aby bylo jasno, ja mam linost na haskellu rad. Ale i kdyz se clovek jeste pohybuje na ciste FP uzemi, tak tam rozdily jsou a ne ciste jenom ve prospech lenosti.)

[Ondra Satai Nekola]

Co na tom příkladu není jasné? Jaká smyčka?

Ivan s tim ma problem a tak si mysli, ze je to problem

[Mirek Prýmek]

To je naprosto normalni semantika striktniho jazyka.

Kind of. Céčko třeba žádné nekonečné listy nemá, čili to jeho sémantika není. A ano, je nesmyslná. Protože první tři prvky z nekonečného listu jsou dobře definované první tři prvky. Není to nedefinovaná hodnota jako třeba 1/0.

Čili pokud budeš vědět, že k tomuhle problému by u tvého jazyka mohlo dojít, tak tam vůbec nekonečné listy nedáš, nebo je tam dáš v symbolické formě, u které k zacyklení dojít nemůže (tak to má např. Elixir, který je eager, nekonečné listy má a nezacykluje se na nich).

Spotreba pameti. Dokud nedojde na ⊥, tak se u striktnich jazyku lepe resi pametova narocnost.

To už ale mluvíš o implementaci, ne o jazyku.

[andy]

Jaký význam má pojem "nelínost" u pure jazyka? Že se občas zacyklí na něčem, na čem by se zacyklit nemusel? Vlastnost líný/nelíný prostě zásadně ovlivňuje chování u ne-pure jazyků, ale u pure jazyků nemá na nic vliv (kromě tohodle případu, kde je jenom na škodu).

Teď jsem se nějak zamotal.... ale Haskell je líný v té pure části, efektové části musí být v monadu a ten se líně nevyhodnocuje... tak v čem je teda problém?
Jinak co třeba tuhle úžasnost, jejíž varianta se např. používá ve FRP:

Kód: [Vybrat]

forkService :: (Service -> IO ()) -> IO Service
forkService svcCode = mdo
  let service = Service "New service" threadid
  theadid <- forkIO (svcCode service)
  return service
Tohle chce trochu lenosti, a přesto víš, co se kdy přesně vyhodnotí.

[Mirek Prýmek]

efektové části musí být v monadu a ten se líně nevyhodnocuje...

Jaktože ne?

[Ondra Satai Nekola]

To je naprosto normalni semantika striktniho jazyka.

Kind of. Céčko třeba žádné nekonečné listy nemá, čili to jeho sémantika není.

Ale, ale.

Kód: [Vybrat]

int foo() { for (;;); }

int bar(a, b) { return a; }

bar(1,foo());
a zase mas ⊥ (jenom tomu proste Ceckar tak nerika, protoze zije v jinem svete)

[Mirek Prýmek]

Ale, ale.

Kód: [Vybrat]

int foo() { for (;;); }

int bar(a, b) { return a; }

bar(1,foo());
a zase mas ⊥ (jenom tomu proste Ceckar tak nerika, protoze zije v jinem svete)

To je ale úplně jiný případ. Tím jsi jenom ilustroval, že se v céčku dá napsat kód, který se zacyklí.

[andy]

efektové části musí být v monadu a ten se líně nevyhodnocuje...

Jaktože ne?

Tak teď nevím, jestli se ptáš na tu úžasnou teorii nebo na praxi pod tím, ale standardně neexistuje možnost napsat něco typu, co jsi napsal:

Kód: [Vybrat]

let a = print "hello"
let b = print "world"
f a b
Resp. to nedělá to, že by to nedeterministicky vyhodnotilo "a" a "b". Takže když se bavím o laziness v případě efektů, tak ta v haskellu prostě neexistuje (vyjma unsafePerformIO, ale to je něco, jako když v jakémkoliv jiném jazyce odskočíš do assembleru). Dobře, můžeš tvrdit, že IO Monad se vyhodnocuje nějak "líně" tím, že se tam protahuje přes všechny funkce RealWord#, ale to je prostě nějaké teoretické zdůvodnění - prakticky se to prostě vyhodnocuje "eager" (teda mě není vůbec moc jasné, co vlastně v případě monadu má znamenat "lazy" a "strict"....)

[Ondra Satai Nekola]

Ale, ale.

Kód: [Vybrat]

int foo() { for (;;); }

int bar(a, b) { return a; }

bar(1,foo());
a zase mas ⊥ (jenom tomu proste Ceckar tak nerika, protoze zije v jinem svete)

To je ale úplně jiný případ. Tím jsi jenom ilustroval, že se v céčku dá napsat kód, který se zacyklí.

To je furt ten samy pripad. (pokud mas problem s tim [1..], tak si vezmi ten priklad s

Kód: [Vybrat]

def foo = foo
take(3, [1,2,3,4,foo])

ten ti taky 'konci' bud [1,2,3] nebo ⊥)

Ve striktnim jazyce cokoli v podobe baz(..., ⊥, ...) je ⊥. V non-strict muze a nemusi.