Příspěvky

886

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 18:49:25 »

Matoucí mi přijde říkat tomu funkce, je to spíš "něco jako" enum s dodatečnými daty (ostatně ve Swiftu to je oficiálně enum). Pak se taky lépe vysvětluje pattern matching.
U té správnosti si nejsem jistý, protože podrobně neznám Haskell, třeba to v něm funkce je, ale obecně to v FP neplatí.

Mně právě přijde rozumný se na to dívat jako na funkci - nevím o tom, že by někde šla použít funkce a ne data contructor (tím neříkám, že to neexistuje, jenom o tom nevím). U speciálního typu i Haskell wiki mluví o funkci:

Smart constructors are just functions

https://wiki.haskell.org/Smart_constructors

Dalo by se data konstruktor od normální funkce odlišit, ale moc nevím, k čemu by to bylo dobrý. Naopak neodlišovat to mi přijde fakt elegantní, páč pak můžeš s klidem udělat třeba:

Prelude> map Just [1,2,3]
[Just 1,Just 2,Just 3]

Teď z hlavy si neumím vybavit všechny souvislosti, ale třeba ty monády by se asi ještě zkomplikovaly, kdybys tu distinkci dělal.

Nechci se pouštět do diskuze, fakt Haskell moc neznám. Ale z určitého pohledu to smysl dává, ten poslední příklad je celkem hezký a vlastně to třeba v tom Swiftu píšu stejně de facto podvědomě, aniž bych se nad tím pozastavoval. Za ten příklad u mě máš, jak říkával můj profesor fyziky, "malé bezvýznamné plus"

887

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 18:16:37 »

Teď jsi to napsal trochu zmateně a nejsem si jist, že úplně správně.

Proč zmateně a včem myslíš, že ne správně? (nehádám se, je to možný, proto mě to zajímá)

Matoucí mi přijde říkat tomu funkce, je to spíš "něco jako" enum s dodatečnými daty (ostatně ve Swiftu to je oficiálně enum). Pak se taky lépe vysvětluje pattern matching.
U té správnosti si nejsem jistý, protože podrobně neznám Haskell, třeba to v něm funkce je, ale obecně to v FP neplatí.

888

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 17:56:33 »

5. jsem zkoušel, ale teď teprve vím, že "data" je jen funkce a začíná mi to dávat logiku.

"data" samo o sobě je klíčové slovo, ne funkce. To, o co jde, je, že data contructor je vlastně funkce. Když mám třeba

Kód: [Vybrat]

Prelude> data MujParadniTyp = PismenkovaHodnota String | CiselnaHodnota Int

tak máme vlastně dvě funkce, které mi ze Stringu nebo Intu vytvoří MujParadniTyp

Kód: [Vybrat]

Prelude> :t PismenkovaHodnota
PismenkovaHodnota :: String -> MujParadniTyp

Prelude> :t CiselnaHodnota
CiselnaHodnota :: Int -> MujParadniTyp

- v podstatě tu hodnotu zavřou do krabice. Krabice může obsahovat String nebo Int hodnotu a krabice samotná má typ MujParadniTyp. V pythonu by se pro podobnej efekt použil tuple:

Kód: [Vybrat]

("PismenkovaHodnota","hola hola")
("CiselnaHodnota",1)

by odpovídalo Haskellovskému

Kód: [Vybrat]

(PismenkovaHodnota  "hola hola")
(CiselnaHodnota 1)

- v Haskellu se krabice prostě dá udělat funkcí a můžu pak dělat pattern matching, to by ve většině jazyků nešlo - funkce je pro ně něco, co jde jenom spustit. Pro Haskell ne

A tohodle "zavírání do krabic" se právě chytře používá mj. v těch monádách. A protože krabice i její obsah je vždycky haskellovský typ, tak ta funkce CiselnaHodnota je ze stejné kategorie do stejné kategorie a je to ... tramtadadá! ... ten slavný endofunktor! (EDIT: teda respektive byl by, pokud by byl nadefinovaný pro libovolný typ, ne jenom pro String)

Teď jsi to napsal trochu zmateně a nejsem si jist, že úplně správně.

889

Vývoj / Re:Má Haskell budoucnost?

« kdy: 20. 05. 2016, 17:04:05 »

... Symboly => -> :: apod. jsou pro mne stále stěží čitelné.

No, tak jsem si docela dost jistý, že třeba <- je funkce. A vůbec by měl nepřekvapilo, kdyby :: byla funkce pro definování typové anotace.

Ve škole jsme takové symboly vůbec nepoužívali, takže nemám na co navazovat. Proto jsou pro mne nové.

No tak to je jasný.

Jsem spíše narážel na to, že z tradičnějších jazyků je člověk zvyklí na takovou tu omáčku: class, function, return, ... A v Haskellu není prostě nic. Jen výrazy. Každý kousíček kódu je nějaká funkce, která má nějakou signaturu, což znamená, že má někde vstup a vrací jeden výstup. (A ok, pár výjimek by se tam samozřejmě našlo.)

Třeba == je funkce. Nebo [] je konstruktor, taky funkce. (Teď doufám, že už se neseknu.)

A oproti Lispu má výhodu v té funkcionálnosti. Že se dá na funkce koukat jako na krabičky, které mají jasně odlišený vnitřek a venek. Což zase ohromě osvobozuje myšlení. Ale tady už skutečně odjíždím do offtopicu.

Absence "omáčky" je záměrná, protože to je výhoda, mozek ji nemusí kognitivně odfiltrovávat.

890

Vývoj / Re:Má Haskell budoucnost?

« kdy: 20. 05. 2016, 16:41:15 »

Ono toho zatím moc není. Mám ještě stále problémy se čtením symbolů, které bývají v jiných jazycích slovní, ale v Haskellu jsou tvořeny posloupností nealfanumerických znaků. Časem si na to zvyknu a teprve pak to ocením.

Tohle mě třeba taky štve. Číst kód, který je směsicí >> >>= << <=< $ <$> kde některé z nich fungují "zprava doleva" a některé naopak, je peklo. Občas mám pocit, že to snad haskellisti dělají schválně, aby okolí ukázali "já na to mám"

To je jen o zvyku, ne? Je to prostě jen konvence.

891

Vývoj / Re:Má Haskell budoucnost?

« kdy: 20. 05. 2016, 13:25:28 »

Mimochode, jak se v Haskell řeší mutable stav? Je zde například key-value úložiště?

O tom je celé tohle vlákno: monády, monády, monády...

892

/dev/null / Jak peníze ničí vysoké školy

« kdy: 19. 05. 2016, 13:56:10 »

FYI: http://student.e15.cz/agora/michal-tomes-jak-penize-nici-vysoke-skoly-1295981

Nový příspěvek do věčné diskuze, tentokrát celkem hodnotný a hodný zamyšlení.

893

Vývoj / Re:Má Haskell budoucnost?

« kdy: 18. 05. 2016, 15:16:42 »

Bude k tomu nějaký materiál?

Myslíš třeba jako kilo koksu?

Je to první setkání, asi spíš jenom pokec.

To neberu/koksem netopím (neznám tě tak dobře, abych tvou otázku mohl úspěšně disambiguovat ).

894

Vývoj / Re:Má Haskell budoucnost?

« kdy: 18. 05. 2016, 14:40:11 »

POZOR REKLAMA POZOR REKLAMA POZOR REKLAMA

Kdybyste někdo měli zájem, tento čtvrtek 19.5. se v Brně koná první sraz zájemců o Elm:

http://www.meetup.com/Brno-Elm-Meetup/events/230668222/

Bude k tomu nějaký materiál?

895

Vývoj / Re:Má Haskell budoucnost?

« kdy: 18. 05. 2016, 13:07:56 »

Tak ten vtip zní "A monad is just a monoid in the category of endofunctors". Tak prozatím to chápu tak, že "monoid" znamená v podstatě "list" nebo "stream" a "kategorie endofunktorů" znamená, že jsem z té akce v listu schopen vytáhnout hodnotu a nějak ji předat následujícím akcím..

Tak to chápeš blbě Monoid znamená, že pro tu věc platí pravidla monoidu (asociativita a existence neutrálního prvku) a endofunktor je funktor, který mapuje kategorii na sebe samu.

Endofunktor je to proto, že libovolný haskellovský typ mapuje opět na haskellovský typ. A monoid je to proto, že bind je asociativní a return je neutrální prvek.

...ale neřekl bych, že by komukoli "normálnímu" tahle definice pomohla pochopit, o co jde

On to hlavně není vtip, takto to formuloval Mac Lane (vytrženo z kontextu to zní ovšem trochu abstrakně).

Pochopit tu definici je užitečné k hlubšímu vhledu do problematiky, ale nehodí se k prvotnímu vysvětlení.

... a nebyl by ochoten mi to někdo teda vysvětlit? Když už jsme u toho, tak by mě to docela zajímalo. Monoid je asociativní - monoid je operace >>=. Operace >>= je řetězení operací za sebe. V monadu to znamená řetězení instrukcí za sebe (<> taky může počítat maximum). Takže se na to taky dá dívat jako na List, který interpret pomocí fold (>>=) interpretuje. Nebo nedá?

A endofunktor v té definici teda znamená co?

Předpokládám znalost definice monoidu a základních pojmů z teorie kategorií. Místo nosné množiny se vezme nějaký endofunktor nad nějakou kategorií, řekněme T. Místo operace nad monoidem (něříkám násobení, taky může být aditivní, prostě nějaká funkce o dvou parametrech tak, aby to byl monoid) se vezme přirozená transformace μ (jako multiplication) T∘T do T a místo unit elementu se vezme přirozená transformace η (jako identity) 1 do T (1 je id endofunktor). Nejdou tu kreslit komutativní diagramy, takže v symbolech: μ∘Tμ=μ∘μT a μ∘Tη=μ∘ηT=1 (první rovnost si vynucuje asociativitu a druhá identitu zleva a zprava). Žádná magie v tom není.

896

Vývoj / Re:Má Haskell budoucnost?

« kdy: 18. 05. 2016, 01:05:13 »

Tak ten vtip zní "A monad is just a monoid in the category of endofunctors". Tak prozatím to chápu tak, že "monoid" znamená v podstatě "list" nebo "stream" a "kategorie endofunktorů" znamená, že jsem z té akce v listu schopen vytáhnout hodnotu a nějak ji předat následujícím akcím..

Tak to chápeš blbě Monoid znamená, že pro tu věc platí pravidla monoidu (asociativita a existence neutrálního prvku) a endofunktor je funktor, který mapuje kategorii na sebe samu.

Endofunktor je to proto, že libovolný haskellovský typ mapuje opět na haskellovský typ. A monoid je to proto, že bind je asociativní a return je neutrální prvek.

...ale neřekl bych, že by komukoli "normálnímu" tahle definice pomohla pochopit, o co jde

On to hlavně není vtip, takto to formuloval Mac Lane (vytrženo z kontextu to zní ovšem trochu abstrakně).

Pochopit tu definici je užitečné k hlubšímu vhledu do problematiky, ale nehodí se k prvotnímu vysvětlení.

897

Vývoj / Re:Má Haskell budoucnost?

« kdy: 17. 05. 2016, 17:35:15 »

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

898

Vývoj / Re:Má Haskell budoucnost?

« kdy: 17. 05. 2016, 16:17:29 »

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.

899

Vývoj / Re:Má Haskell budoucnost?

« kdy: 17. 05. 2016, 13:36:12 »

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

900

Vývoj / Re:Má Haskell budoucnost?

« kdy: 17. 05. 2016, 12:57:45 »

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