Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.Tak pokud nekdo scita nebo odcita boolean, tak mu to patriNo a to je právě ono - operátor dělá pokaždé něco jinýho, podle toho, jaký použiju parametry. Je fakt, že u JS je tou pravou příčinou zběsilý přetypování, ale výsledek je stejnej..
A co je podle tebe rozšíření skalárního součinu na komplexní čísla? Najednou přestane být komutativní, takže "začne mít jiné vlastnosti", ale přitom je definovaný úplně stejným vzorečkem.hlavně ale interpretace toho co vektor znamená nemá vliv na sčítání vektorů, asiJá bych to asi řekl tak, že o "zobecnění" se dá mluvit tam, kde nějakou operaci aplikuju na něco jinýho za zachování všech vlastností té operace - což je taky ten princip za type classes. Když mám třeba operaci sčítání na celých číslech (+_Z) a operaci sčítání na reálných číslech (+_R), tak můžu smyslupně mluvit o tom, že +_R je zobecněním +_Z.
Jakmile ale použiju stejnej symbol v jiným kontextu, kde začne mít jiný vlastnosti, tak mi to nepřijde jako zobecnění, ale jenom prostě jako použití stejnýho symbolu pro jinou operaci.
U součinu už jen skalární součin, ale zase třeba u matic je třeba přiznat, že se berou spíše jako skládání, protože matice představují funkce (transformace). Jinak u těch řetězců to taky smysl má, na konkatenaci řetězců se dá prostě dívat jako na aditivní monoid, použitý symbol je jen konvence.U plus mě taky nic nenapadá, ale u součinu už anoU součinu jo, třeba násobení matic žejo. Ale to beztak vzniklo tak, že nějakýho poťapanýho matematika nenapadlo nic lepšího, než pro něj použít stejnej symbol a pak už se s t tím nic nedalo dělat. Matematici vůbec se symboly pracují dost volně a kreativněJako člověka odchovanýho programováním mě v matice vždycky rozčilovalo, jak se občas někde vypustí nějakej index, protože "všichni ví, že se tím myslí ...."
Jasně, že to je komutativní, sčítání vektorů ostatně vůbec nezávisí na okolním prostoru, to se učí snad už na základce (kterou Kit, podle toho, jak se tu projevuje, evidentně nedokončil). Na kouli je nekomutativní skládání paralelních přenosů tečných vektorů, to ale vůbec nesouvisí se sčítaním a je to docela pokročilý koncept v diferenciální geometrii.Například sčítání dvou 2D vektorů na povrchu Země.To je pořád komutativní, ne?
U plus mě taky nic nenapadá, ale u součinu už anoPodstatné je to slovo "obecně". V Euklidovském prostoru samozřejmě komutativita sčítání platí.Obecně pokud pro operaci x neplatí komutativita, tak dost dobře nemá smysl takovou operaci označovat symbolem "+". Máš nějaký příklad zaužívaného "+", které není komutativní? Mě fakt nenapadá (pokud teda nepočítám ty programátorské úlety).
Jak už zmínili jiní, tohle správné (pevné) pořadí nezajistí, nicméně funkcionální by bylo něco jakostrict: před vyhodnocením funkce jsou vyhodnoceny její argumentyV tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:Kód: [Vybrat]- dle té definice by pořadí výpisu nutně bylo a,b. Funkce f a g můžou dělat cokoli, může to být klidně identita.f(print "b",g(print "a"))
No jasně, tak rozdíl mezi pure funkcí a IO akcí. Ale opakuju otázku - co je na IO monádu složitého? Ten monád je doslova (jak jsi psal) to, že pouští jeden "příkaz" za druhým. Žádné výhybky tam nejsou, žádné nedeterministické větvení, nic. Co na tom je složitého? Je to středník, který je naprogramovaný jako středník, takže "do" se chová tak, jak by člověk ve většině programovacích jazyků čekal ("return" na první pohled nevypadá jako šťastná volba, ale po několika kapitolách pure programování mě teda ani nenapadlo, že by to snad tu funkci mělo ukončit - to jsem fakt spíš bojoval s tím, kdy použít "let" a kdy "<-").Tobě "do" syntaxe připadá složitá? Jediný, co potřebuješ pochopit, je rozdíl mezi pure a non-pure funkcí.Žádné non-pure fce ale neexistují
Taky se v tom začínám ztrácet, ale tak nějak ty tady v zásadě pořád říkáš, že laziness v zásadě způsobuje složitost haskellu a následně se takové věci jako řazení IO musí řešit přes monády. Já bych asi i souhlasil s tím, že to byl historický vývoj, ale dostali jsme se někam, kde se ukazuje, že to sice na začátku jako opičárna vypadala, ale vlastně to byl docela dobrý nápad.
- v pure výpočtech je laziness celkem putna, mnohdy je spíš lepší
- haskell je v zásadě celý pure včetně IO
- podle tebe je celé IO opičárna, ale mě nějak vůbec není jasné, co by mělo být lepší. Přestat si v IO hrát na pure programování, a pak když se rozhodneš, že místo IO použiješ nějaký Free, nebo to obalíš RWS, tak ten refaktoring bude znamenat přepisování do nějaké jiné syntaxe? Nebo že ti překladač bude automaticky detekovat, jestli je funkce v IO nebo ne a v nějaké syntaxi typu "f(print "a", print "b")" to bude nějak automaticky vyhodnocovat... a pak začneš řešit "ale co když to vyhodnotit nechci" a "v jakém pořadí se to má vyhodnotit".... není to trochu komplikace?
Jo, ono je občas užitečné se ponořit do teorie a v klidu si nějaké abstraktnější věci promyslet. Pro volné chvíle doporučuji kryptomonádyaspoň mám důvod či záminku dostudovat trochu teorie, zároveň si říkám, že takové debaty se asi vedly o kvantové fyzice nebo kvazikrystalechJo, je to možnéJá bych je spíš popsal jako "sofistikovaný způsob dosažení cíle bez narušení a priori daných self-imposed principů".není možné, že jste opět diplomatický?Nicméně formálně opravdu "čisté" (ve smyslu FP) jsou.osobně s čistotou IO v haskellu nemám žádný filosofický ani jiný problém, ale najdou se tací, kteří mají, i tady na rootu se o tom vedly dabatyJinak mi je čistota Haskellu úplně ukradená, jen se mi prostě líbí použití dost abstraktního konceptu (monády) na něco praktického, nicméně přiznávám, že v tomto případě mně zajímá hlavně ta formální (matematická) stránka věci, protože funkcionálně píšu jen v jazycích převážně imperativních. Konkrétně u Haskellu mi ta debata navíc přijde dost žabomyší.
Jo, je to možnéJá bych je spíš popsal jako "sofistikovaný způsob dosažení cíle bez narušení a priori daných self-imposed principů".není možné, že jste opět diplomatický?Nicméně formálně opravdu "čisté" (ve smyslu FP) jsou.osobně s čistotou IO v haskellu nemám žádný filosofický ani jiný problém, ale najdou se tací, kteří mají, i tady na rootu se o tom vedly dabaty
Jinak mi je čistota Haskellu úplně ukradená, jen se mi prostě líbí použití dost abstraktního konceptu (monády) na něco praktického, nicméně přiznávám, že v tomto případě mně zajímá hlavně ta formální (matematická) stránka věci, protože funkcionálně píšu jen v jazycích převážně imperativních. Konkrétně u Haskellu mi ta debata navíc přijde dost žabomyší.
hack je možná trochu silné slovo, ani netvrdím, že nejsou užitečná i jinde, sám je používám až příliš, nicméně viz "tackling the awkward squad"To není tak úplně pravda. Monády jsou "čisté" ve smyslu FP. Navíc tam nejsou jen pro IO. Chce to ale ponořit se trochu hlouběji do matematického aparátu, jenž za nimi stojí.Mě naopak připadá, že dát tam nějaký hack kvůli tomu, že chceš IO popsat nějak jinak, než všechno ostatní, co děláš, by nebylo úplně dobré....proč si něco nalhávat? monády v haskellu jsou hack kvůli potřebě popsat IO a udržet zbytek čistý
Jen jsem to napsal trochu diplomatičtějiTo není tak úplně pravda.Není to ani trochu pravda.
To není tak úplně pravda. Monády jsou "čisté" ve smyslu FP. Navíc tam nejsou jen pro IO. Chce to ale ponořit se trochu hlouběji do matematického aparátu, jenž za nimi stojí.Mě naopak připadá, že dát tam nějaký hack kvůli tomu, že chceš IO popsat nějak jinak, než všechno ostatní, co děláš, by nebylo úplně dobré....proč si něco nalhávat? monády v haskellu jsou hack kvůli potřebě popsat IO a udržet zbytek čistý
Přesně o tom monády jsou a upřímně fakt nevím, proč o nich někdo pochybuje.CitaceProstě pokud v líném jazyce chceš vynutit pořadí, uděláš to třeba pomocí monády a pokud chceš vynutit línost v nelíném jazyce, uděláš to třeba pomocí futures. Oboje jde a ani jedno neporušuje línost/nelínost toho jazyka. Je to jenom způsob, jak ho nějakou fintou donutit udělat něco, co by jinak "sám od sebe" negarantoval.A není to nakonec Monad docela hezký způsob jak popsat, co má program dělat? Jak bys to popsal jinak? Monad je způsob, jak něco popíšeš, je to datová struktura, se kterou jsi schopen nějak pracovat a vyhodnocovat ji. V ostatních jazycích mi připadá, že funkce je de-fakto "black-box". Monad ten black-box vlastně umožní rozložit. Ale když se ti to nelíbí, tak vůbec nemusíš řešit, jak to funguje - (IO x) ber jako "pointer na funkci", a když to vložíš do těla IO funkce, tak se vykoná. A jsi zpátky v normálních jazycích, v čem je problém?
Různé sémantiky pro symbolický systém jsou probémem obecně a nejen v CS, viz např. formální logika a různé sémantiky pro různé dedukční systémy nebo teorie množin a její různé modely (např. ten Gödelův). V IT je to jen názornější, protože na rozdíl od matematických teorií se programy výpočetně vyhodnocují, takže si člověk - když napíše něco blbě nebo si není vědom sématického problému - rychle nabije čumák. Nejhezčí příklad, o němž vím, je v Prologu SLD rezoluce vs. SLG, v té druhé se žádný program nikdy nezacyklí, kdežto v té první je problémem jakákoliv levá rekurze, např. něco jako borders(X, Y) :- borders(Y, X). Čili nemá moc smysl se tu o tom dále hádat, neboť problém je trochu jinde.take(3,[1..])Ok, beru. Jistě můžu mít jazyk s libovolně nesmyslnou sémantikou. Třeba takovou, že 1+1 = ⊥ nebo take(3,[1..]) = ⊥. Takže formálně máš pravdu, uznávám. Bavíme se ale o tom, jestli by takový jazyk mělo smysl vytvářet. Já říkám, že si nedovedu moc představit, k čemu by bylo dobré mít pure jazyk bez línosti.
ma jinou hodnotu podle toho, jaky mas jazyk. Muze to byt [1,2,3] nebo ⊥
Jaký význam má pojem "nelínost" u pure jazyka? Že se občas zacyklí na něčem, na čem by se zacyklit nemusel? Vlastnost líný/nelíný prostě zásadně ovlivňuje chování u ne-pure jazyků, ale u pure jazyků nemá na nic vliv (kromě tohodle případu, kde je jenom na škodu).
U ne-pure jazyků totiž výraz musím vyhodnotit pokaždé, kdy mě zajímá jeho hodnota. U pure jazyka mi stačí ho vyhodnotit jednou. Proto je mi celkem jedno, kdy to udělám. V principu bych tu tvoji sémantiku mohl korektně naplnit i tak, že si předem zjistím, že se program nutně dostane k vyhodnocování take(3,[1..]), takže se na celý program vykašlu a hned spustím "for( ; ; ) ;"
To je právě ono, laziness je v takovém případě irelevantní a vztahuje se jen na implementaci (kde má smysl o ní uvažovat). Proto píšu, že jsou to koncepty ortogonální. Asi jsem se špatně vyjádřil, považuju za poněkud nešťastné o "(non)laziness" vůbec uvažovat, protože při zachování rozumných vlastností (především té již zmíněné čistoty) není smysluplné o ní mluvit.Právě proto nerozumím tomu, proč jim říkáš ortogonální. Podle mě jsou naopak vzájemně závislé přesně z tohodle důvodu.
Ale to je jedno, nebudem slovíčkařit
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.