Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: LambdaBender 12. 07. 2018, 14:53:26
-
Ahoj, učím se Haskell a zajímalo by mě, jestli lze v Hasku nějak formálně vyjádřit dědičnost. Odpovídá dědičnosti (podtypům) nějaká matematická vlastnost nebo relace? Možná mi něco uniklo, ale v Hasku vidím jen typové konstruktory, ne vyjádření vlastnosti být podtypem.
-
Ahoj, učím se Haskell a zajímalo by mě, jestli lze v Hasku nějak formálně vyjádřit dědičnost. Odpovídá dědičnosti (podtypům) nějaká matematická vlastnost nebo relace? Možná mi něco uniklo, ale v Hasku vidím jen typové konstruktory, ne vyjádření vlastnosti být podtypem.
Typove tridy uz jsi videl?
https://en.wikibooks.org/wiki/Haskell/Classes_and_types#Class_inheritance
Ten koncept rozsirovani chovani je o neco oddlenejsi od rozsirovani datovych struktur nez v Java/C++/Ruby.. style.
Polymorfismus muzes casto vyjadrit tak, ze proste mas vic funkci se stejnym typem a nekterou z nich mas nekam "prirazenou".
-
Ahoj, učím se Haskell a zajímalo by mě, jestli lze v Hasku nějak formálně vyjádřit dědičnost. Odpovídá dědičnosti (podtypům) nějaká matematická vlastnost nebo relace? Možná mi něco uniklo, ale v Hasku vidím jen typové konstruktory, ne vyjádření vlastnosti být podtypem.
Typove tridy uz jsi videl?
https://en.wikibooks.org/wiki/Haskell/Classes_and_types#Class_inheritance
Ten koncept rozsirovani chovani je o neco oddlenejsi od rozsirovani datovych struktur nez v Java/C++/Ruby.. style.
Polymorfismus muzes casto vyjadrit tak, ze proste mas vic funkci se stejnym typem a nekterou z nich mas nekam "prirazenou".
Viděl. Šlo mi o to, jak se klasifikují matematicky. Například monády jsou funktory (splňující nějaké podmínky navíc), tak jestli je nějaký čistě formální koncept, jehož reflexí je v praxi dědičnost. Bohužel ten matematický aparát nijak podrobně neznám.
-
Šlo mi o to, jak se klasifikují matematicky. Například monády jsou funktory (splňující nějaké podmínky navíc), tak jestli je nějaký čistě formální koncept, jehož reflexí je v praxi dědičnost. Bohužel ten matematický aparát nijak podrobně neznám.
Množiny a podmnožiny?
Čísla -> Celá čísla -> Rozsah celých čísel.
Ale vlastní podtypovou dědičnost v Haskellu neumím. (Třídy jo, ale to je něco jiného.)
-
myslím, že tohle haskellu neexistuje, asi
(možná pomůže tahle klasika https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf )
-
Šlo mi o to, jak se klasifikují matematicky. Například monády jsou funktory (splňující nějaké podmínky navíc), tak jestli je nějaký čistě formální koncept, jehož reflexí je v praxi dědičnost. Bohužel ten matematický aparát nijak podrobně neznám.
Množiny a podmnožiny?
To právě ne, typy jsou formálně objekty Hasku, jež jsou nedělitelné. Proto se všechno vyjadřuje pomocí šipek, jen ty podtypy mi nějak unikají. Ještě zkouším stackoverflow, tak uvidíme.
-
Set Theory a Cathegory Theory ... Haskell je vice mene o matematice, sice jedne z nejabstraktnejsich domen co existuje ale +- z 99% presne o nich.
Na jakoukoliv cast Haskellu jde najit vedeckou praci na ktere je zalozena
-
Šlo mi o to, jak se klasifikují matematicky. Například monády jsou funktory (splňující nějaké podmínky navíc), tak jestli je nějaký čistě formální koncept, jehož reflexí je v praxi dědičnost. Bohužel ten matematický aparát nijak podrobně neznám.
Ale vlastní podtypovou dědičnost v Haskellu neumím
Haskell to asi nemá, ale v teorii by to mohl být klasifikátor podobjektů (teď jsem o tom našel článek Milewského). Ale nevím ještě přesně, tohle je pro mě nové.
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
Čistě funkcionální není, má kupříkladu závislostní typy. Proč by nemohl mít podtypy, když má všechny předpoklady (jednotkový typ, pravdivostní objekt)? Normálně by stačila syntaktická podpora pro klasifikátor podobjektů. Haskellisti sice někdy vymýšlejí šílené kraviny (viz derivace typů pro zippery), ale v tomto případě by byl dopad i praktický.
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
Čistě funkcionální není, má kupříkladu závislostní typy.
Můžeš ukázat jak závislostní typy poškodí referenční transparentnost?
Proč by nemohl mít podtypy, když má všechny předpoklady (jednotkový typ, pravdivostní objekt)? Normálně by stačila syntaktická podpora pro klasifikátor podobjektů. Haskellisti sice někdy vymýšlejí šílené kraviny (viz derivace typů pro zippery), ale v tomto případě by byl dopad i praktický.
Tak v OOP má dědičnost dopad vysloveně tragický. Třeba (třeba ne) by to mělo nějaké nešikovné důsledky.
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
Čistě funkcionální není, má kupříkladu závislostní typy.
Můžeš ukázat jak závislostní typy poškodí referenční transparentnost?
Nemůžu. Ani jsem to netvrdil.
-
Proč by nemohl mít podtypy, když má všechny předpoklady (jednotkový typ, pravdivostní objekt)? Normálně by stačila syntaktická podpora pro klasifikátor podobjektů. Haskellisti sice někdy vymýšlejí šílené kraviny (viz derivace typů pro zippery), ale v tomto případě by byl dopad i praktický.
Tak v OOP má dědičnost dopad vysloveně tragický.
Ano, to je pravda. Viděno zpětně neměl jsem použít pojem dědičnost, jenže právě jak jsem psal, dost jsem tápal v té formální rovině, než jsem si našel texty o těch klasifikátorech. Správně by bylo hovořit o podtypech a jejich klasifikátorech. Dovedu si představit, jak by jejich podpora v syntaxi usnadnila implementaci a ušetřila psaní kódu. Ještě mě čeká dost rešerší a studia této problematiky, ale je-li zájem o diskusi, podívejme se na nějaké příklady.
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
Čistě funkcionální není, má kupříkladu závislostní typy.
Můžeš ukázat jak závislostní typy poškodí referenční transparentnost?
Nemůžu. Ani jsem to netvrdil.
Možná ti to nedošlo, ale pojem čistě funkcionální == referenční transparentnost. Tak jak jsi to tedy myslel? Proč by neměl být Haskell čistě funkcionální?
Proč by nemohl mít podtypy, když má všechny předpoklady (jednotkový typ, pravdivostní objekt)? Normálně by stačila syntaktická podpora pro klasifikátor podobjektů. Haskellisti sice někdy vymýšlejí šílené kraviny (viz derivace typů pro zippery), ale v tomto případě by byl dopad i praktický.
Tak v OOP má dědičnost dopad vysloveně tragický.
ušetřila psaní kódu.
To zní děsivě povědomě!
ale je-li zájem o diskusi, podívejme se na nějaké příklady.
Za mě jo. Máš-li co, ukaž.
-
Haskell je cisto funkcionalny, tam by som rozhodne dedicnost netahal a ani o nej nerozmyslal (typove triedy su nieco ine).
Čistě funkcionální není, má kupříkladu závislostní typy.
Můžeš ukázat jak závislostní typy poškodí referenční transparentnost?
Nemůžu. Ani jsem to netvrdil.
Možná ti to nedošlo, ale pojem čistě funkcionální == referenční transparentnost. Tak jak jsi to tedy myslel? Proč by neměl být Haskell čistě funkcionální?
tak flame o tom co je čistě funkcionální už tu dlouho nebyl, to je pravda :))
-
ale je-li zájem o diskusi, podívejme se na nějaké příklady.
Za mě jo. Máš-li co, ukaž.
K zamyšlení: Mám funkci f:B->R a A je podtypem B. Chci použít f na hodnoty A. Aby to prošlo typovou kontrolou, dám klasifikátoru charakteristický morfismus a mám tím pádem funkci A->R (protože klasifikátor mi dá funkci pro injekci do B na základě isomorfismu, takže stačí běžná kompozice funkcí, která by šla aplikovat automaticky syntaktickým cukrem). Tohle je asi nejjednodušší příklad, zajímavější to je u podtypů funkcí.
-
ale je-li zájem o diskusi, podívejme se na nějaké příklady.
Za mě jo. Máš-li co, ukaž.
K zamyšlení: Mám funkci f:B->R a A je podtypem B. Chci použít f na hodnoty A. Aby to prošlo typovou kontrolou, dám klasifikátoru charakteristický morfismus a mám tím pádem funkci A->R (protože klasifikátor mi dá funkci pro injekci do B na základě isomorfismu, takže stačí běžná kompozice funkcí, která by šla aplikovat automaticky syntaktickým cukrem). Tohle je asi nejjednodušší příklad, zajímavější to je u podtypů funkcí.
to mi připomíná typovou třídu s asociovanou rodinou typů nebo trochu data types a la carte ( http://mpickering.github.io/posts/2014-12-20-closed-type-family-data-types.html )
-
Proč by nemohl mít podtypy, když má všechny předpoklady (jednotkový typ, pravdivostní objekt)? Normálně by stačila syntaktická podpora pro klasifikátor podobjektů. Haskellisti sice někdy vymýšlejí šílené kraviny (viz derivace typů pro zippery), ale v tomto případě by byl dopad i praktický.
Tak v OOP má dědičnost dopad vysloveně tragický.
ušetřila psaní kódu.
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější. Nicméně otázka byla, jak podtypování dosáhnout, praktické dopady jsou na jinou diskuzi.
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
Já bych tady OOP vůbec nezmiňoval. I když je pravda, že jakmile se dostaneme k podtypům funkcí, narazíme na varianci, což se obvykle používá jen v OO kontextu. Nicméně právě ta kategoriální interpretace naznačuje, že jde o koncept funkcionální (viz λ-kostka).
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
Já bych tady OOP vůbec nezmiňoval. I když je pravda, že jakmile se dostaneme k podtypům funkcí, narazíme na varianci, což se obvykle používá jen v OO kontextu. Nicméně právě ta kategoriální interpretace naznačuje, že jde o koncept funkcionální (viz λ-kostka).
Já OOP uváděl jen a pouze jako příklad zvrhnutí se dědičnosti. Tedy jsem se pouze ptal, zda by se v Haskellu nestalo něco podobného. Jinak mě OOP (v tomto kontextu) zas až nezajímá.
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
Já bych tady OOP vůbec nezmiňoval. I když je pravda, že jakmile se dostaneme k podtypům funkcí, narazíme na varianci, což se obvykle používá jen v OO kontextu. Nicméně právě ta kategoriální interpretace naznačuje, že jde o koncept funkcionální (viz λ-kostka).
Já OOP uváděl jen a pouze jako příklad zvrhnutí se dědičnosti. Tedy jsem se pouze ptal, zda by se v Haskellu nestalo něco podobného. Jinak mě OOP (v tomto kontextu) zas až nezajímá.
Zvrhnout by se to mohlo, a sice různými směry, nicméně stále si myslím, že by převážily výhody. Když si například udělám charakteristický morfimsus z obdélníku do čtverce, dostanu zadarmo všechny relevantní funkce. Dokonce by šly automaticky optimalizovat.
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
Já bych tady OOP vůbec nezmiňoval. I když je pravda, že jakmile se dostaneme k podtypům funkcí, narazíme na varianci, což se obvykle používá jen v OO kontextu. Nicméně právě ta kategoriální interpretace naznačuje, že jde o koncept funkcionální (viz λ-kostka).
Já OOP uváděl jen a pouze jako příklad zvrhnutí se dědičnosti. Tedy jsem se pouze ptal, zda by se v Haskellu nestalo něco podobného. Jinak mě OOP (v tomto kontextu) zas až nezajímá.
Zvrhnout by se to mohlo, a sice různými směry, nicméně stále si myslím, že by převážily výhody. Když si například udělám charakteristický morfimsus z obdélníku do čtverce, dostanu zadarmo všechny relevantní funkce. Dokonce by šly automaticky optimalizovat.
a už jsi u code reusability :-D aby z toho BoneFlute netrefil šlak
-
To zní děsivě povědomě!
Pokus o flame? Kratší program je přehlednější a vesměs efektivnější.
Vo tom žádná. Já narážím spíše na obecně rozšířenou praxi OOP vývojářů, kteří dědičnost používají zhusta čistě za účelem reusable kódu. Což mi doufám uznáš, že je děsivé.
Já bych tady OOP vůbec nezmiňoval. I když je pravda, že jakmile se dostaneme k podtypům funkcí, narazíme na varianci, což se obvykle používá jen v OO kontextu. Nicméně právě ta kategoriální interpretace naznačuje, že jde o koncept funkcionální (viz λ-kostka).
Já OOP uváděl jen a pouze jako příklad zvrhnutí se dědičnosti. Tedy jsem se pouze ptal, zda by se v Haskellu nestalo něco podobného. Jinak mě OOP (v tomto kontextu) zas až nezajímá.
Zvrhnout by se to mohlo, a sice různými směry, nicméně stále si myslím, že by převážily výhody. Když si například udělám charakteristický morfimsus z obdélníku do čtverce, dostanu zadarmo všechny relevantní funkce. Dokonce by šly automaticky optimalizovat.
a už jsi u code reusability :-D aby z toho BoneFlute netrefil šlak
Jemu nevadí "code reusability" per se, ale zneužití dědičnosti ke "code reusability".
-
dostanu zadarmo všechny relevantní funkce. Dokonce by šly automaticky optimalizovat.
Tohle by šlo ještě rozvést, díky pattern matchingu by se původní výraz (definovaný pro nějaký nadobjekt) mohl automaticky zjednodušit během překladu podle charakteristického morfismu (reduction to constant).
-
a už jsi u code reusability :-D aby z toho BoneFlute netrefil šlak
Jemu nevadí "code reusability" per se, ale zneužití dědičnosti ke "code reusability".
Přesně tak.
Dědičnost ve smyslu množin: Byte je speciální případ Integeru, ten je speciální případ Numberu - to je dědičnost naprosto v pořádku. Ale je to dost umělý příklad, a je otázka, jak by to "fungovalo". Na druhou stranu, v drtivém množství případů použiješ spíše třídy, a ty Haskell má.
-
a už jsi u code reusability :-D aby z toho BoneFlute netrefil šlak
Jemu nevadí "code reusability" per se, ale zneužití dědičnosti ke "code reusability".
Dědičnost ve smyslu množin
To je právě scestné uvažování. V kategoriích žádné množiny nejsou, veškeré vztahy se vyjadřují pomocí vztahů, objekty se považují za nedělitelné. Podobjekty se například definují přes kartézské čtverce. Možná proto je FP tak nepochopitelné, všichni jsou zvyklí na množiny a pak přijde někdo s algebrou... :)