Má Haskell budoucnost?

[zboj]

Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.

To by tam ale nesmělo být přetypování na int ani by nesměl být true definovaný jako 1 (což je myslím v C).

Jasně, v C to je jako v assembleru, jen říkám, že to jde udělat logicky, ne že to tak jazyky mají.

Ja bych rekl, ze s tim + je problem, ze se kryje s programatory vice pouzivanym a zazitym || nebo or. Jak jste psali vyse (doufam ze to bylo toto vlakno ), IMO jde o podobny konflikt mezi IT a matematikou.

Samozřejmě, používání symbolů je vždy o konvenci a nejde ani tak o konflikt, jako o prostý rozdíl ve značení. Nicméně matematika tu byla dříve, takže tam, kde to jde, by si informatici neměli vymýšlet blbosti a raději převzít zavedené značení.

[Reklama]

[JS]

Haskell budoucnost rozhodne ma, dokazuje to i tato diskuse. Spousta diskutujicich Haskell evidentne zna. Ale asi nikdy nebude uplne mainstream.

Jinak Haskell je v podstate dnes standard pro temer jakekoli CS clanky, ktere se tykaji programovacich jazyku.

[pr]

S Haskell jsem skončil, když nepochopil, to jsou to monády.... :-(

Takže, abych si to ujasnil...
1) Pro používání monád je nemusím chápat...
2) Haskell je pure, ale v monádách se může klidně programovat imperativně...
3) V monádách  klidně můžou existovat mutable typy...
4) Ten, kdo chápe monády, je nedokáže dobře vysvětlit...

[zboj]

S Haskell jsem skončil, když nepochopil, to jsou to monády.... :-(

Takže, abych si to ujasnil...
1) Pro používání monád je nemusím chápat...
2) Haskell je pure, ale v monádách se může klidně programovat imperativně...
3) V monádách  klidně můžou existovat mutable typy...
4) Ten, kdo chápe monády, je nedokáže dobře vysvětlit...

Pojem monáda je magický, lidi si ten koncept totiž neumí nijak rozumně představit, ale přitom je používají - nevědomky - ve vlastních programech. Doporučuji články na Wikipedii, je jich tam k monádám několik.

[Mirek Prýmek]

Takže, abych si to ujasnil...

TL;DR: ani jedno z toho, co pises, neni pravda tak, jak to pises

1) Pro používání monád je nemusím chápat...

Monady jsou mj. prostredek, jak v pure+lazy jazyce dosahnout souslednosti nejakych operaci. Cili je to vyborny zpusob, jak v pure+lazy jazyce psat IO. Neni to ale jediny zpusob. V principu muzes delat IO i bez znalosti monad, ale monady jsou lepsi.

2) Haskell je pure, ale v monádách se může klidně programovat imperativně...

Monady jsou zpusob, jak v pure+lazy psat imperativnim stylem (tj. psat posloupnost operaci, ktere se provedou ve stejnem poradi, jak jsem je napsal).

3) V monádách  klidně můžou existovat mutable typy...

Ne.

4) Ten, kdo chápe monády, je nedokáže dobře vysvětlit...

Vetsina lidi asi ne Ale existuji i dobra vysvetleni. Mne se treba libi, ze Learn you a Haskell mluvni prvne o IO a az o par kapitol dal o monadach. Pokud to nepochopis z tohodle textu a za radneho snazeni se, tak asi Haskell neni vhodny jazyk pro tebe (bez jakekoliv urazky - to je proste fakt, ne kazdemu ten zpusob uvazovani musi vyhovovat).

[Reklama]

[pr]

... V Haskellu je pro tyto účely tzv. ST monad, který de-fakto umožňuje provádět mutable programování v "izolaci" - tzn. ta mutabilita je uvnitř a neuteče nikam ven. Mně připadá, že ale výsledný kód má do přehlednosti dost daleko - je to takové ... imperativní ...

Jinak je pravda, že jsem tomu zase tolik nedal... přeci jen, Erlang se mi zalouvá více...

[Mirek Prýmek]

... V Haskellu je pro tyto účely tzv. ST monad, který de-fakto umožňuje provádět mutable programování v "izolaci" - tzn. ta mutabilita je uvnitř a neuteče nikam ven. Mně připadá, že ale výsledný kód má do přehlednosti dost daleko - je to takové ... imperativní ...

Jinak je pravda, že jsem tomu zase tolik nedal... přeci jen, Erlang se mi zalouvá více...

To, co pise gl, je zavadejici. Zadna mutabilita tam neni. Stejne jako funkce s typem IO nejsou "neciste". Vsechno je porad ciste a imutabilni, akorat existuje zpusob, jak i presto dosahovat nejakych vnejsich efektu.

[BoneFlute]

To, co pise gl, je zavadejici. Zadna mutabilita tam neni. Stejne jako funkce s typem IO nejsou "neciste". Vsechno je porad ciste a imutabilni, akorat existuje zpusob, jak i presto dosahovat nejakych vnejsich efektu.

A nebo čistě a funkcionálně říct, že chceme nějakého efektu.

Mimochodem to se týká hlavně IO operací. Funkcionálnost s pořadím imho nutně nekoliduje. Pokud tedy chápu správně, že FP je o referenční transparentnosti a pravidle, kdy funkce je ovlivňována jen argumenty. Jen je to občas problém jak funkcionálně vyjádřit následnost.

[Mirek Prýmek]

Funkcionálnost s pořadím imho nutně nekoliduje. Pokud tedy chápu správně, že FP je o referenční transparentnosti a pravidle, kdy funkce je ovlivňována jen argumenty. Jen je to občas problém jak funkcionálně vyjádřit následnost.

Pokud mas referencni transparentnost, tak to znamena, ze jakykoliv vyraz muzes vyhodnotit predem, ulozit si vyslednou hodnotu do tabulky a kdyz priste narazis na stejny vyraz, dosadis tam jenom hodnotu z tabulky. Takze z tehle definice pak muzes vyrazy vyhodnocovat v libovolnem poradi. A jedine, u ceho by te poradi vyhodnocovani mohlo zajimat, je IO. U vseho ostatniho je ti to putna

[Mirek Prýmek]

Jinak je pravda, že jsem tomu zase tolik nedal... přeci jen, Erlang se mi zalouvá více...

Hodnej hoch! Cim vic erlangistu, tim lepsi svet!

Nicmene mam pro tebe takovou pomucku, jak mozna to do notaci pochopis lip, hele, vubec to neni slozity:

Mas ucebnicovy priklad:

Kód: [Vybrat]

main = do
  putStrLn "Hello, what's your name?"
  name <- getLine
  putStrLn ("Hey " ++ name ++ ", you rock!")

to "do" a "<-" je jenom syntaktickej cukr, ve skutecnosti je to zkratka pro tohle:

Kód: [Vybrat]

main =
  (putStrLn "Hello, what's your name?") >>
    (getLine >>= (\name -> putStrLn ("Hey " ++ name ++ ", you rock!")))

Vsimni si tam te lambdy "\name ->". Operator (>>=) dela to, ze rika "vystup prvni IO akce prived na vstup lambdy, ktera vraci druhou IO akci". A operator (>>) dela to same, akorat vystup prvni IO akce zahodi. Takze muzeme operator (>>) nahradit obecnejsim (>>=) a kod dal prevest na:

Kód: [Vybrat]

main =
  (putStrLn "Hello, what's your name?") >>=
    (\_ ->
      getLine >>=
        (\name -> putStrLn ("Hey " ++ name ++ ", you rock!"))
    )

No a ted si musime jenom ujasnit, ze tenhle kod porad nic nevykonava, je to jenom staticky popis toho, jake akce by se mely provest, v jakem poradi a jaka si maji predavat data. Operator (>>=) pouziva ty divne monady:

Kód: [Vybrat]

Prelude> :t (>>=)
(>>=) :: Monad m => m a -> (a -> m b) -> m b
...takze se jich zbavime taky!

Kód: [Vybrat]

import GHC.Base (bindIO)

main =
  bindIO
    (putStrLn "Hello, what's your name?")
    (\_ ->
      bindIO
        getLine
        (\name -> putStrLn ("Hey " ++ name ++ ", you rock!"))
    )
...funkce bindIO nedela nic jineho nez ze dva RECEPTY na IO (staticky popis IO akci) posklada za sebe, cimz vznikne nova IO akce zahrnujici ty dve:

Kód: [Vybrat]

Prelude GHC.Base> :t bindIO
bindIO :: IO a -> (a -> IO b) -> IO b

Jak vidis, abys delal IO v Haskellu, monady nepotrebujes. Postupovali jsme opacnym zpusobem, nez jde abstrakce: k razeni IO potrebujes otravne lambdy, takze je fajn si zavest operatory, ktere te od nich odstini. No a kdyz mas tohle, tak si jeste zavedes dalsi syntakticky cukr, ktery to jeste cely obali tak, aby to vypadalo jakoze imperativni programovani. Co to pripomina? No prece promises s JS! Protoze to jsou taky de facto monady. Akorat o tom nikdo nemluvi, nikdo z toho timpadem nema strach a vsichni to naprosto v klidu pouzivaji

[zboj]

Jinak je pravda, že jsem tomu zase tolik nedal... přeci jen, Erlang se mi zalouvá více...

Hodnej hoch! Cim vic erlangistu, tim lepsi svet!

Nicmene mam pro tebe takovou pomucku, jak mozna to do notaci pochopis lip, hele, vubec to neni slozity:

Mas ucebnicovy priklad:

Kód: [Vybrat]

main = do
  putStrLn "Hello, what's your name?"
  name <- getLine
  putStrLn ("Hey " ++ name ++ ", you rock!")

to "do" a "<-" je jenom syntaktickej cukr, ve skutecnosti je to zkratka pro tohle:

Kód: [Vybrat]

main =
  (putStrLn "Hello, what's your name?") >>
    (getLine >>= (\name -> putStrLn ("Hey " ++ name ++ ", you rock!")))

Vsimni si tam te lambdy "\name ->". Operator (>>=) dela to, ze rika "vystup prvni IO akce prived na vstup lambdy, ktera vraci druhou IO akci". A operator (>>) dela to same, akorat vystup prvni IO akce zahodi. Takze muzeme operator (>>) nahradit obecnejsim (>>=) a kod dal prevest na:

Kód: [Vybrat]

main =
  (putStrLn "Hello, what's your name?") >>=
    (\_ ->
      getLine >>=
        (\name -> putStrLn ("Hey " ++ name ++ ", you rock!"))
    )

No a ted si musime jenom ujasnit, ze tenhle kod porad nic nevykonava, je to jenom staticky popis toho, jake akce by se mely provest, v jakem poradi a jaka si maji predavat data. Operator (>>=) pouziva ty divne monady:

Kód: [Vybrat]

Prelude> :t (>>=)
(>>=) :: Monad m => m a -> (a -> m b) -> m b
...takze se jich zbavime taky!

Kód: [Vybrat]

import GHC.Base (bindIO)

main =
  bindIO
    (putStrLn "Hello, what's your name?")
    (\_ ->
      bindIO
        getLine
        (\name -> putStrLn ("Hey " ++ name ++ ", you rock!"))
    )
...funkce bindIO nedela nic jineho nez ze dva RECEPTY na IO (staticky popis IO akci) posklada za sebe, cimz vznikne nova IO akce zahrnujici ty dve:

Kód: [Vybrat]

Prelude GHC.Base> :t bindIO
bindIO :: IO a -> (a -> IO b) -> IO b

Jak vidis, abys delal IO v Haskellu, monady nepotrebujes. Postupovali jsme opacnym zpusobem, nez jde abstrakce: k razeni IO potrebujes otravne lambdy, takze je fajn si zavest operatory, ktere te od nich odstini. No a kdyz mas tohle, tak si jeste zavedes dalsi syntakticky cukr, ktery to jeste cely obali tak, aby to vypadalo jakoze imperativni programovani. Co to pripomina? No prece promises s JS! Protoze to jsou taky de facto monady. Akorat o tom nikdo nemluvi, nikdo z toho timpadem nema strach a vsichni to naprosto v klidu pouzivaji

Nechtěl bys napsat nějaký Yet another monad tutorial?

S monádami to je jako s Rudým baronem, všichni britští piloti věděli, že je nesestřelitelný, a soubojům s ním se vyhýbali, až přišel nováček z Kanady, sotva opustivší vojenskou školu pro piloty, který o něm v životě neslyšel a při prvním letu ho sundal

[gl]

... V Haskellu je pro tyto účely tzv. ST monad, který de-fakto umožňuje provádět mutable programování v "izolaci" - tzn. ta mutabilita je uvnitř a neuteče nikam ven. Mně připadá, že ale výsledný kód má do přehlednosti dost daleko - je to takové ... imperativní ...

Jinak je pravda, že jsem tomu zase tolik nedal... přeci jen, Erlang se mi zalouvá více...

To, co pise gl, je zavadejici. Zadna mutabilita tam neni. Stejne jako funkce s typem IO nejsou "neciste". Vsechno je porad ciste a imutabilni, akorat existuje zpusob, jak i presto dosahovat nejakych vnejsich efektu.

To jsem nepsal já. Byla to odpověď andyho na mou otázku. Pochopil jsem to tak, že mutabilita tam je. Co jiného dělá writeSTRef?

[Mirek Prýmek]

To jsem nepsal já. Byla to odpověď andyho na mou otázku. Pochopil jsem to tak, že mutabilita tam je. Co jiného dělá writeSTRef?

Nevim, ja s tim praktickym Haskellem nemam zkusenosti. Ale predpokladam, ze to bude neco ve smyslu retezeni lambd, kde kazda vezme hodnotu a vrati jinou (nebo stejnou). Takze "zmena hodnoty" pak znamena za ten retezec lamb pridat dalsi.

Nebo tak neco Ale kazdopadne porad je to nejakej figl jak simulovat vlastnosti mutability v imutabilnim prostredi.

[Mirek Prýmek]

Nechtěl bys napsat nějaký Yet another monad tutorial?

Naopak - to neni navod k monadam, to je navod, jak pochopit IO v Haskellu pomoci ostentativniho ignorovani pojmu monada

[v]

Nechtěl bys napsat nějaký Yet another monad tutorial?

Naopak - to neni navod k monadam, to je navod, jak pochopit IO v Haskellu pomoci ostentativniho ignorovani pojmu monada

spíš přitroublého ignorování, bindIO není standardní haskell, ale ghc