Dědičnost funkcionálně

[LambdaBender]

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í.

[Reklama]

[v]

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 )

[LambdaBender]

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.

[BoneFlute]

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é.

[LambdaBender]

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).

[Reklama]

[BoneFlute]

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á.

[LambdaBender]

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.

[sentai]

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

[LambdaBender]

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".

[LambdaBender]

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).

[BoneFlute]

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á.

[LambdaBender]

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...