Má Haskell budoucnost?

[zboj]

Když na tím teď tak přemýšlím, tak mě zarazilo, že tomu říkáš endofunktor, ten by měl operovat na jiné úrovni, ale třeba jsem to jen blbě pochopil.

No to máš asi pravdu, to byl ukvapenej závěr, jehož problematičnost jsem si hned uvědomil a chtěl poladit tím editem, ale ani tak si nejsem jistej, jestli jsem nenapsal blbost

Pokud bysme měli kategorii haskellovských typů, tak funkce jsou morfismy a datakonstruktorem D můžeš mapovat

f: a -> b

na

f: D a -> D b

takže funktor to je a protože i (D a) je haskellovský typ, tak by to měl být endofunktor.

...ovšem pokud přijmeme, že konstruktor je normální funkce, tak se nám to trochu pomotá a nevím, jestli by to pak takhle šlo říct, protože tímpádem by to byl morfismus.

No, hele, s tím si musíš poradit spíš ty, pro mě je to na pokraji mých znalostí

Pořád si myslím, že mícháš dvě různé věci. "CiselnaHodnota" nebo něco takového je morfismus, ale funktory se aplikují na morfismy, ne hodnoty. Každopádně tomu asi rozumíme oba a jen se trochu popletla terminologie.

[Reklama]

[Mirek Prýmek]

ale funktory se aplikují na morfismy, ne hodnoty. Každopádně tomu asi rozumíme oba a jen se trochu popletla terminologie.

No to sice jo, ale když máš to f: D a -> D b, tak jsi vlastně f (tj. morfismus) liftnul z jedné kategorie ({a,b}) do druhé ({D a, D b}). Nejsem si jistej, jestli je korektní říct o D samotném, že je to funktor. Spíš by na to musel být ještě jiný symbol, označující tu vlastní operaci f -> D(f). Každopádně v Haskellu se functor říká té vlastní věci, která se mapuje přes hodnoty:

Kód [Vybrat] Rozbalit


class Functor f where
  fmap :: (a -> b) -> f a -> f b


Ale nevylučuju, že to teď motám, momentálně mám v hlavě spíš to, že jsem si koupil http://store.steampowered.com/app/319630/ a nemůžu se dočkat, až si to zahraju

[zboj]

ale funktory se aplikují na morfismy, ne hodnoty. Každopádně tomu asi rozumíme oba a jen se trochu popletla terminologie.

No to sice jo, ale když máš to f: D a -> D b, tak jsi vlastně f (tj. morfismus) liftnul z jedné kategorie ({a,b}) do druhé ({D a, D b}). Nejsem si jistej, jestli je korektní říct o D samotném, že je to funktor. Spíš by na to musel být ještě jiný symbol, označující tu vlastní operaci f -> D(f). Každopádně v Haskellu se functor říká té vlastní věci, která se mapuje přes hodnoty:

Kód [Vybrat] Rozbalit


class Functor f where
  fmap :: (a -> b) -> f a -> f b


Ale nevylučuju, že to teď motám, momentálně mám v hlavě spíš to, že jsem si koupil http://store.steampowered.com/app/319630/ a nemůžu se dočkat, až si to zahraju

Teď jsi to zamotal ještě víc Kategorii máme přece jen jednu. Mně šlo jen o to, že to D funktor není.

[Mirek Prýmek]

Kategorii máme přece jen jednu.

No ano, ale je to prostě mapování odněkud někam a mapuješ funkce. I když prakticky to je aplikace na hodnoty, což je matoucí.

No ať je to jak chce, jdu konečně hrát, hezký zbytek večera

[zboj]

Kategorii máme přece jen jednu.

No ano, ale je to prostě mapování odněkud někam a mapuješ funkce. I když prakticky to je aplikace na hodnoty, což je matoucí.

No ať je to jak chce, jdu konečně hrát, hezký zbytek večera

Já to radši shrnu, ať to nějak rozmotáme (tím "liftnutím" se to zamotalo příliš). Mějme

Kód [Vybrat] Rozbalit

protocol Boxable {}
enum Box {
    case Some(Boxable)
}
extension Int : Boxable {}
let list = [1, 2, 3].map(Box.Some)
print(list)
Na Box.Some se dá dívat jako na morfismus z Boxable na Box, což jsou objekty naší jediné kategorie. Funktor (každý je endofunktorem) může mapovat třeba právě Boxable na Box nebo Box.Some na něco, ale samotné Box.Some funktorem není (v kategorii typů, v Haskellu tedy Hask).

P.S. Užij si hraní

[Reklama]

[Mirek Prýmek]

Máš pravdu, náčelníku. Functor není ten konstruktor, ale typ, který je pomocí něho definovaný:

instance  Functor Maybe  where
    fmap _ Nothing       = Nothing
    fmap f (Just a)      = Just (f a)

Parádně jsem se v tom zamotal, po ránu s čistou hlavou to jde líp

[andy]

Tak další praktický příklad strictness vs. laziness. Potřebuju na kliknutí vybrat nějakou barvu a přiřadit ji nějaké kresbě. Kreseb může být víc. Když odkliknu a kliknu, rád bych, aby tam byla stejná barva. V lazy haskellu:

Kód [Vybrat] Rozbalit

let colors = map genColor [1..]
A je to. Můžu to dát do IORefu nebo nějakého stavu.

Kód [Vybrat] Rozbalit

atomicModifyIORef ioref ((,) <$> drop 1 <*> head) je následující barva. Když uživatel odklikne, vyměním stav na

Kód [Vybrat] Rozbalit

modifyIORef ioref (puvodni_barva :)"
A je to. Jenže to potřebuju udělat ve striktním purescriptu... a než abych se zabýval, jak to udělat lazy listem, tak asi zvolím nějaké "náhradní" řešení (typu konečný seznam barev).
Ne, že by to člověk potřeboval často, ale občas se to prostě hodí... a explicitní thunkování není úplně příjemné na pohled.

[Radek Miček]

Ne, že by to člověk potřeboval často, ale občas se to prostě hodí...

To je ovšem jádro problému - za něco, co není potřeba příliš často, platíte velmi vysokou cenu. A navíc je obtížnější to použít s vedlejšími efekty, např. v IO monádě:

Kód [Vybrat] Rozbalit


-- ideálně bychom nechtěli počítat x a y, pokud se nepoužijí uvnitř case, zde se ovšem spočítají
x <- necoSloziteho a1 a2 a3
y <- necoSloziteho2 x a4 a5 a6  -- závisí na x
case neco of
  A -> -- použije se y
  B -> -- nepoužije se x ani y
  C -> -- použije se x (y nehceme počítat)
  D -> -- použije se y


Například ve Scale to jde snadno zařídit, aby se x a y nepočítaly, pokud nejsou použity:

Kód [Vybrat] Rozbalit


lazy val x = necoSloziteho(a1, a2, a3)
lazy val y = necoSloziteho2(x, a4, a5, a6)  // závisí na x
neco match {
  case A => // použije se y
  case B => // nepoužije se x ani y
  case C => // použije se x (y nehceme počítat)
  case D => // použije se y
}


[v]

Ne, že by to člověk potřeboval často, ale občas se to prostě hodí...

To je ovšem jádro problému - za něco, co není potřeba příliš často, platíte velmi vysokou cenu. A navíc je obtížnější to použít s vedlejšími efekty, např. v IO monádě:

Kód [Vybrat] Rozbalit


-- ideálně bychom nechtěli počítat x a y, pokud se nepoužijí uvnitř case, zde se ovšem spočítají
x <- necoSloziteho a1 a2 a3
y <- necoSloziteho2 x a4 a5 a6  -- závisí na x
case neco of
  A -> -- použije se y
  B -> -- nepoužije se x ani y
  C -> -- použije se x (y nehceme počítat)
  D -> -- použije se y


Například ve Scale to jde snadno zařídit, aby se x a y nepočítaly, pokud nejsou použity:

Kód [Vybrat] Rozbalit


lazy val x = necoSloziteho(a1, a2, a3)
lazy val y = necoSloziteho2(x, a4, a5, a6)  // závisí na x
neco match {
  case A => // použije se y
  case B => // nepoužije se x ani y
  case C => // použije se x (y nehceme počítat)
  case D => // použije se y
}


to "lazy" nějak memoizuje?

[Radek Miček]

to "lazy" nějak memoizuje?

Ano.

[v]

to "lazy" nějak memoizuje?

Ano.

jak se to liší od let + unsafePerformIO?

[Radek Miček]

jak se to liší od let + unsafePerformIO?

Například nehrozí, že si tím otevřete díru do typového systému (s pomocí unsafePerformIO můžete napsat coerce) - na rozdíl od jazyků z rodiny ML nemá Haskell value restriction nebo jiný podobný mechanismus, který by tomu zabránil. Ve Scale jsou zase všechny hodnoty monomorfní - problém tam také nehrozí.

[andy]

jak se to liší od let + unsafePerformIO?

Neliší. Je to stejná prasárna. Znamená to "netuším, kdy se tyhle efekty provedou a je mi to jedno". I s unsafePerformIO (nebo unsafeInterleaveIO) se člověk musí snažit, aby ten coerce napsal, o to nejde. Jde o to, že člověk neví, kdy se efekty provedou. V Haskellu existuje věc jménem "getContent" pro čtení ze souboru, která je lazy. V produkčních programech by se neměla ani náhodou objevit, protože přestože vypadá "referenčně transparentní", tak v momentě, kdy si ten "file handle" zavřete, tak najednou přestane být.

Výsledkem pak je, že pokud se někde v tomhle "lazy" kódu stane výjimka, tak je člověk pak překvapený, kde mu ta výjimka vyskakuje....

Například ve Scale to jde snadno zařídit, aby se x a y nepočítaly, pokud nejsou použity:

Kód [Vybrat] Rozbalit


lazy val x = necoSloziteho(a1, a2, a3)
lazy val y = necoSloziteho2(x, a4, a5, a6)  // závisí na x
neco match {
  case A => // použije se y
  case B => // nepoužije se x ani y
  case C => // použije se x (y nehceme počítat)
  case D => // použije se y
}


Tohle ale není problém:

Kód [Vybrat] Rozbalit


x <- necoSloziteho a1 a2 a3
let ry = necoSloziteho2 x a4 a5 a6  -- závisí na x
case neco of
  A -> do
           y <- ry-- použije se y
           ..
  B -> -- nepoužije se x ani y
  C -> -- použije se x (y nehceme počítat)
  D -> do
           y <- ry -- použije se y
           ...

Tak vlastně kýženého efektu dosáhnu a je zcela jasné, KDE se y s vedlejšími efekty použilo. Pokud chci přesně vědět a specifikovat, kde to y použiju, tak to asi jinak nejde - a mě se to moc líbí

[andy]

Aha, už to vidím.... ve větvi C je nepoužije se ani jedno... jo, to by se muselo nějak vymyslet "jinak", explicitně. 

Scalu neznám, IMO rozdíl oproti unsafePerformIO bude, že tohle bude fungovat jenom ve scope té funkce, aby ta laziness právě nemohla "utéct" moc daleko. No, ale když už jsme u toho použití, tak tohle jsem zatím nepotřeboval, laziness v pure kódu využívám přece jen častěji...

[Black]

Fakt nechapu co tu resite...

monada je JEN sekvence operaci, NIC JINEHO. Je to zpusob jak ve funkcionalnim jazyku popsat, ze abych z hodnoty y spocital z, potrebuju k tomu hodnotu x