Dotaz: Jak může funkce pomocí typu ovlivnit, jak bude komponovaná do výrazu

[tacoberu]

Následující popis bude dosti vágní, a dost možná i dost zmatený, protože když by byl konkrétní a ujasněný, tak mám odpověď

Předpokládejme, že máme funkci (rename src desc), která přejmenovává nějaký soubor.

Teď já tuto funkci zavolám dejme tomu třikrát, asi takhle:

(randomseq
	(rename "a.txt" "b.txt")
	(rename "b.txt" "c.txt")
	(rename "c.txt" "d.txt")
	)

Z logiky věci (ačkoliv tento příklad není úplně ideální) nám záleží na pořadí těch příkazů. Ale jak naznačuje název té sekvence, tak mi nic nezabrání, abych ty tři funkce nacpal do sekvence, která pořadí příkazů nezaručuje. Což je samozřejmě blbě.

A mě se jedná o to, jak, pomocí typů můžu zajistit, abych takovou blbost, viz víše nemohl udělat. Znám IOMonády z Haskellu. Jestli je chápu dobře, tak mám naférovku typ sekvence, která zajišťuje seřaditelnost. A pak mám řečeno, že ta funkce může být použita jen a pouze v této sekvenci. Správně?

Jsou i jiné možnosti?

Jen pro zajímavost, nad čím dumám:

Tak například jsem při své úvaze vymyslel, že ta funkce rename, krom dvou jmen souborů bude mět ještě argument IO přijímající stav filesystému. A návratová hodnota bude výsledný stav filesystému. (To aby to bylo pure funkcionální.) Můžu si vymyslet typ, který bude fungovat jako singleton, takže jakákoliv další funkce, která chce pracovat s filesystémem musí tuto hodnotu "pustit", aby s tím mohla jiná funkce pracovat. Což se mi líbí. Hezky to řeší synchronizaci. Ale už to neřeší pořadí. Jak může funkce pomocí svého typu ovlivnit, jak bude komponovaná do výrazu?

Odpovědi

[graviton]

Jazyk? Něco lispoidního? Zřejmě se někomu pokoušíš sdělit, že funkce rename má vedlejší efekty. Komu? Kompilátoru? Uživateli?

http://stackoverflow.com/questions/7254514/would-the-ability-to-declare-lisp-functions-pure-be-beneficial <-jakási diskuse o tom, co by znamenalo deklarovat funkcionální čistotu vůči kompilátoru

http://www.cs.sfu.ca/CourseCentral/310/pwfong/Lisp/4/tutorial4.html <- v lispu se dá programovat i imperativně, když má člověk chuť

Jistě je možné stav fs něčím reprezentovat a předávat si to. Nejsou monády zrovna o tom?

Co je přesně cílem? Zabránit uživateli jazyka, aby si střelil do nohy?

[tacoberu]

Jazyk? Něco lispoidního?

Žádný konkrétní jazyk, jen jsem chtěl popsat problém, a zvolil jsem lispovsko syntax.

Zřejmě se někomu pokoušíš sdělit, že funkce rename má vedlejší efekty. Komu? Kompilátoru? Uživateli?

Kompilátoru. Ale ono není jisté, zda se jedná o vedlejší efekt, když výsledek vracím v návratové hodnotě.

Jistě je možné stav fs něčím reprezentovat a předávat si to. Nejsou monády zrovna o tom?

Jsou. A existuje i jiný způsob?

A navíc, mě ani nejde tak o ten stav, jako spíše o tu nutnost zachovat pořadí (a ano, i o tom právě monády jsou).

Co je přesně cílem? Zabránit uživateli jazyka, aby si střelil do nohy?

Defakto ano. Přesněji potřebuji kompilátorovi říct: "Hele, až tohle budeš optimalizovat, tak nezapomeň zachovat pořadí."

[graviton]

Ok, takže obecná úvaha o návrhu programovacího jazyka či prostředí.

není vedlejší efekt, když výsledek vracím v návratové hodnotě.

(rename "a.txt" "b.txt")

Výsledkem je přejmenování souboru na souborovém systému, ten typ návratové hodnoty bych chtěl vidět.

Leda by to právě "stav souborového systému" žralo na vstupu a zas ho to vyhazovalo na výstupu.

Alternativně viz jedna z těch linkovaných úvah o "pure deklaraci" mít u všech knihovních funkcí informaci o jejich čistotě (absenci vedlejších efektů) a dokazovací systém, který si pro uživatelem zadefinovanou věc umí odvodit jestli je čistá nebo ne a bude přerovnávat jen ty čisté. Pak to může dělat takové legrácky, že bude výsledky pure funkcí cachovat, což může některé rekurzivní programy dost zrychlit (memoizace).

[tacoberu]

Ok, takže obecná úvaha o návrhu programovacího jazyka či prostředí.

Tak.

není vedlejší efekt, když výsledek vracím v návratové hodnotě.

(rename "a.txt" "b.txt")

Výsledkem je přejmenování souboru na souborovém systému, ten typ návratové hodnoty bych chtěl vidět.

Leda by to právě "stav souborového systému" žralo na vstupu a zas ho to vyhazovalo na výstupu.

Ano, ano, takto jsem to myslel. "Plná" deklarace té funkce by byla něco jako: (rename io src desc) -> io

Alternativně viz jedna z těch linkovaných úvah o "pure deklaraci" mít u všech knihovních funkcí informaci o jejich čistotě (absenci vedlejších efektů) a dokazovací systém, který si pro uživatelem zadefinovanou věc umí odvodit jestli je čistá nebo ne a bude přerovnávat jen ty čisté. Pak to může dělat takové legrácky, že bude výsledky pure funkcí cachovat, což může některé rekurzivní programy dost zrychlit (memoizace).

Chápu to dobře, že to "jiné" řešení spočívá v tom, že se taková funkce prostě jenom označí, že u ní záleží na pořadí? Hmm, a jak může kompilátor zjistit, že víše uvedenou konstrukci nesmí přeložit? Mě napadá právě jen to, že sekvence randomseq má typovou signaturu, že přijímá pouze pure funkce (přesněji, funkce, které deklarovali, že jim na pořadí nezáleží). Myslíš to taky tak? Existují ještě jiné způsoby (krom těch monád)?

[ava]

No nevím, přijde mi nějaké pochybné na tohle používat typový systém.

- Píšeš "Z logiky věci (ačkoliv tento příklad není úplně ideální) nám záleží na pořadí těch příkazů". Tady to tak vypadá - ale jen zdánlivě. Co kdyby jsi se pokoušel ve skutečnosti použitým kódem implementovat nějaký program na (pseudo)náhodné rozmetání souborů na disku (třeba šéfovi, který ti nezvýšil výplatu ?) Chceš, aby takový program nebylo možné implementovat?

- Pokud to zakóduješ do typového systému, ztratíš možnost typově bezpečně vytvářet takové sekvence za běhu (z uživatelského vstupu).

Aniž bych tomu rozuměl, možná bys mohl nějakou inspiraci načerpat zde

https://en.wikipedia.org/wiki/Substructural_type_system

[tacoberu]

No nevím, přijde mi nějaké pochybné na tohle používat typový systém.

- Píšeš "Z logiky věci (ačkoliv tento příklad není úplně ideální) nám záleží na pořadí těch příkazů". Tady to tak vypadá - ale jen zdánlivě. Co kdyby jsi se pokoušel ve skutečnosti použitým kódem implementovat nějaký program na (pseudo)náhodné rozmetání souborů na disku (třeba šéfovi, který ti nezvýšil výplatu ?) Chceš, aby takový program nebylo možné implementovat?

Ano, to si uvědomuji, proto jsem řekl, že ten příklad není ideální. Jde mi o něco takového:

main :: IO ()
main file = do
    putStr $ "Write to file: " ++ file
    h <- openFile file AppendMode
    hPutStr h anytext
    hClose h
    putStrLn "... done"

Kdy mi na tom pořadí záleží, a nemůžu tolerovat, aby mi to překladač přeházel pořadí. Ale je fakt, že ani tady volaný neovlivňuje pořadí. Možná jsem se v tom jen zamotal.

- Pokud to zakóduješ do typového systému, ztratíš možnost typově bezpečně vytvářet takové sekvence za běhu (z uživatelského vstupu).

Tak né nutně. Od toho ten typový system je, že určuje co mohu dělat. A když to určím blbě, tak je to chyba programátora funkce, ne uživatele. Za link díky, nastuduji.

[ava]

Jinak (IO) Monády ti podle mě nijak nepomůžou v tom, co chceš (i když mi tedy není moc jasný co vlastně chceš). IO Monády jsou vlastně akce, které mohou v okolním světě vykonat nějakou IO operaci, a případně z ní vrátit výsledek (např. getLine je typu IO String). Navíc je (pomocí funkce >>=, taktéž zvané bind nebo flatMap) možné vytvořit novou IO monádu z již existující IO monády a funkce, která z výsledku vraceného existující monádou udělá novou.

Příklad (print zjednodušuji tak, aby bral String, ve skutečnosti bere Show a):

getLine :: IO String

print :: String -> IO String

getLine >>= print :: IO String

getLine >>= print vrací IO monádu, která nejprve zavolá getLine, a na výsledek zavolá print.

Pro tebe je důležitý use case s funkcí rename. Jak by jsi dosáhl to, co potřebuješ, když to bude IO monáda?

Jakého vlastně má být typu (zanedbám možnost selhání rename)?

• IO () - přejmenuje ale nic nevrátí?
• IO String - bude vracet název přejmenovaného souboru?
• IO ???

Pokud to bude první případ, nic tě nenutí mít monády v nějakém konkrétním pořadí - nepodařilo se ti dosáhnout to, co chceš.

Pokud to bude druhý případ, můžeš ve skutečnosti vyjádřit vzájemnou vazbu mezi přejmenováními takto:

rename(rename(rename("a.txt", "b.txt"), "c.txt"), "d.txt")

Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...

[tacoberu]

Tady se dostáváme k tomu, že vysvětlujeme Monády na místo mého problému, ale neva.

Já chápu monády jako formu DSLka.

Například zajímavé užití je Promise, kde určíš, co se má provést, ale neurčuješ kdy. (Tam mimochodem taky záleží na pořadí.)

U IO monády je zase jiný požadavek, že specifikuješ co se má stát, ale vlastní vykonání se předá runtime.

Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...

Zásadní hendikep monád je fakt blbej zápis. Dlouho se na to zvyká. Bonus je v separaci kódu od reality.

Když zapíšeš:

rename(rename(rename("a.txt", "b.txt"), "c.txt"), "d.txt")

v céčku a zavoláš, tak ti to pokaždý přejmenuje soubor a.txt, (a když nebude, tak to chcípne). Jenže ty to chceš třeba jen otestovat, nebo to přejmennovat na jiném fs, nebo to přejmenovat v transakci, etc. V takovém případě ti imperativní C začne házet klacky pod nohy. (A to nemluvě o tom, když bych to chtěl strojově číst a chápat. Třeba kůli dokazování nějaké bezpečnosti a tak. Ale to už jsme jinde.)

Takže přejdeš na objekty a uděláš něco jako:

fs = new IO()
fs.rename(fs.rename(fs.rename("a.txt", "b.txt"), "c.txt"), "d.txt")
fs.commit()

A to už jsi jen krůček od Monád.

[tacoberu]

Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...

Zkoušel jsem přepsat do imperativního jazyka Either a Maybe monádu. A je to v nich strašně ale strašně ukecaný.

[tacoberu]

Pro tebe je důležitý use case s funkcí rename. Jak by jsi dosáhl to, co potřebuješ

Moje představa, se kterou si pohrávám je něco takového:

rename (io = getcontext, src:String, dsc: String): String, setcontext(io)

Kdy jakože io je argument s defaultní hodnotou, která se získá načtením z contextu, uvnitř té funkce s ním pracuji jako s dalším argumentem, když chci, můžu ten argument použít. Po zavolání té funkce, se ten argument nahradí za hodnotu v kontextu. Takže při volání ten IO nemusím vůbec používat.

(rename src dsc)

Jenže mi to ty Monády příliš připomíná, tak jsem se začal ptát.

Cílem je udělat čitelnější a pohodlnější zápis těchto druhů funkcí.

[ava]

Co se v praxi občas používá, a třeba by se ti mohlo hodit, jsouPhantom types.

Např. http://stackoverflow.com/questions/28247543

[tacoberu]

Dík, kouknu.