Map vs. FlatMap

ava

Re:Map vs. FlatMap
« Odpověď #105 kdy: 28. 09. 2016, 21:57:01 »
podle mě většina scalistů chápe flatMap jako bind (i když třeba název bind neznají), už třeba pro to, že for-comprehension funguje všude kde je definovaný flatMap
Nějak nechápu strukturu tohodle argumentu.

Scalisti chápou, že X je vlastně Y, protože X je definované na kde čem?

Bind (v tom haskellovském monadickém smyslu) je definovaný tím, že splňuje monad laws:
Kód: [Vybrat]
Left identity: return a >>= f ≡ f a

Right identity: m >>= return ≡ m

Associativity: (m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)
To by mě teda zajímalo, kolik scalistů si s tímhle láme hlavu...

Usekl jsi můj argument v půlce, když ti ho přeložím celý do X Y, tak: Scalisti X ve scale podobně jako haskellisti Y v haskellu, protože používají X ve scale v mnoha stejných případech jako haskellisti Y v haskellu, syntaktický cukr pro X ve scale (for comprehension) je velice podobný syntaktickému cukru pro Y v haskellu (do notation).

Začátečník haskellista si s těmihle zákony taky hlavu neláme, koukni do LYAHFGG kde se poprvé ukáže do-notation (tj. pod pokličou se používá >>=), a o kolik později se probírají monády. Ale časem se k těm zákonům dostane. Scalista to má podobné, asi se k nim dostane později, protože je dost jiných featur, kterými se musí prokousat, ale pokud neustrne ve vývoji, tak ho to nakonec dožene. Když pak začne používat knihovny scalaz nebo cats, dostane do ruky víceméně všechny často používané struktury z haskellu, a důkladnější porozumění flatMapu se stane nezbytné.


Radek Miček

Re:Map vs. FlatMap
« Odpověď #106 kdy: 28. 09. 2016, 22:07:12 »
Otázkou je, co symbol ≡ přesně znamená (zejména, jak se ten symbol chová se seq)?
Znamená, že výraz na pravé a levé straně má vždy stejnou hodnotu.

Jenže pak ty zákony nefungují (pokud stejná hodnota znamená, že jednu stranu mohu nahradit tou druhou, aniž by se změnilo chování programu; změnu v časové složitosti ignorujme). Jako příklad můžeme vzít monádu State Int a ukážeme, že Right identity neplatí.

Za m zvolím undefined :: State Int (). Má tedy platit, že (undefined :: State Int ()) >>= return se chová vždy jako (undefined :: State Int ()). Jenže to neplatí, když výrazy dáme do seq:

Kód: [Vybrat]
seq ((undefined :: State Int ()) >>= return) ()  -- vyhodnotí se na ()
seq (undefined :: State Int ()) ()               -- vyhodí výjimku


Re:Map vs. FlatMap
« Odpověď #107 kdy: 28. 09. 2016, 22:30:00 »
Usekl jsi můj argument v půlce, když ti ho přeložím celý do X Y, tak: Scalisti X ve scale podobně jako haskellisti Y v haskellu, protože používají X ve scale v mnoha stejných případech jako haskellisti Y v haskellu, syntaktický cukr pro X ve scale (for comprehension) je velice podobný syntaktickému cukru pro Y v haskellu (do notation).
X a Y byly jiné věci než rozdíl Scala vs. Haskell, ale nešť :)

Scalista to má podobné, asi se k nim dostane později, protože je dost jiných featur, kterými se musí prokousat, ale pokud neustrne ve vývoji, tak ho to nakonec dožene. Když pak začne používat knihovny scalaz nebo cats, dostane do ruky víceméně všechny často používané struktury z haskellu, a důkladnější porozumění flatMapu se stane nezbytné.
Ok, tak jestli je to tak, tak to je pro mě velmi dobrá a potěšující zpráva.

Jenže pak ty zákony nefungují (pokud stejná hodnota znamená, že jednu stranu mohu nahradit tou druhou, aniž by se změnilo chování programu
No to bude asi tím, že undefined a seq jsou dost speciální případy... Ale do diskuse o detailech se pouštět nebudu, Haskell znám spíš povrchně na to, abych se pouštěl do takových špeků :)

Re:Map vs. FlatMap
« Odpověď #108 kdy: 28. 09. 2016, 23:50:41 »
https://wiki.haskell.org/Seq

...(seq) violates the principle from lambda calculus of extensionality of functions, or eta-conversion...

Radek Miček

Re:Map vs. FlatMap
« Odpověď #109 kdy: 29. 09. 2016, 00:03:00 »
https://wiki.haskell.org/Seq

...(seq) violates the principle from lambda calculus of extensionality of functions, or eta-conversion...

To je pravda. Nicméně bez sequ bude řada programů v GHC Haskellu fungovat špatně (např. jim bude přetékat zásobník) - tj. ignorovat seq mi přijde jako špatný nápad, neboť seq se v reálných programech vyskytuje.


noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Map vs. FlatMap
« Odpověď #110 kdy: 29. 09. 2016, 07:22:08 »
Jsem si celkem jisty, ze flatMap ve Scale neni jen na monadach, takze pokud bind v Haskellu je pouze o monadach, tak flatMap a bind nejsou ekvivalentni. Pamatuju si, ze Erik Meijer v nejakem videu rikal, ze aby to slo hezky pouzit (predpokladam ze ve for-comprehension) je flatMap i na vecech, co nesplnuji monad laws.

PS: Neco jsem k tomu nasel, tak Future to (obecne) nesplnuje - http://stackoverflow.com/a/27467037/1017211.

Re:Map vs. FlatMap
« Odpověď #111 kdy: 29. 09. 2016, 07:58:08 »
https://wiki.haskell.org/Seq

...(seq) violates the principle from lambda calculus of extensionality of functions, or eta-conversion...

To je pravda. Nicméně bez sequ bude řada programů v GHC Haskellu fungovat špatně (např. jim bude přetékat zásobník) - tj. ignorovat seq mi přijde jako špatný nápad, neboť seq se v reálných programech vyskytuje.

To můžeš říct i o unsafe I/O

x14

  • ***
  • 182
    • Zobrazit profil
    • E-mail
Re:Map vs. FlatMap
« Odpověď #112 kdy: 29. 09. 2016, 12:08:47 »
Trochu tápu ve funkcionálním přístupu, jaký je pls rozdíl mezi map a flatMap?
Baví mě, jaká diskuse se tu zvedla kvůli ne zcela jasnému dotazu, ke kterému se autor už dál nevyjadřuje.
Obávám se, že Sancho je Level 12 Troll  :)

andy

Re:Map vs. FlatMap
« Odpověď #113 kdy: 29. 09. 2016, 13:38:45 »
https://wiki.haskell.org/Seq

...(seq) violates the principle from lambda calculus of extensionality of functions, or eta-conversion...

To je pravda. Nicméně bez sequ bude řada programů v GHC Haskellu fungovat špatně (např. jim bude přetékat zásobník) - tj. ignorovat seq mi přijde jako špatný nápad, neboť seq se v reálných programech vyskytuje.
To ano, ale undefined typicky ne. Teda ne že by se někde nějaký bottom nemohl v reálném kódu objevit, ale že by tohle zrovna bylo zdrojem nějaké chyby, to by musela být hodně drsná shoda okolností.

Radek Miček

Re:Map vs. FlatMap
« Odpověď #114 kdy: 29. 09. 2016, 18:17:49 »
https://wiki.haskell.org/Seq

...(seq) violates the principle from lambda calculus of extensionality of functions, or eta-conversion...

To je pravda. Nicméně bez sequ bude řada programů v GHC Haskellu fungovat špatně (např. jim bude přetékat zásobník) - tj. ignorovat seq mi přijde jako špatný nápad, neboť seq se v reálných programech vyskytuje.

To můžeš říct i o unsafe I/O

Ano, to je další položka do seznamu výjimek, kde zákony pro monády neplatí (unsafe I/O je však horší, protože může rozbít typový systém).