Dědičnost funkcionálně

LambdaBender

Re:Dědičnost funkcionálně
« Odpověď #15 kdy: 13. 07. 2018, 14:04:51 »
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í.


v

Re:Dědičnost funkcionálně
« Odpověď #16 kdy: 13. 07. 2018, 14:20:37 »
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

Re:Dědičnost funkcionálně
« Odpověď #17 kdy: 13. 07. 2018, 14:49:53 »
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

  • *****
  • 1 823
    • Zobrazit profil
Re:Dědičnost funkcionálně
« Odpověď #18 kdy: 13. 07. 2018, 15:04:13 »
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

Re:Dědičnost funkcionálně
« Odpověď #19 kdy: 13. 07. 2018, 15:14:06 »
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).


BoneFlute

  • *****
  • 1 823
    • Zobrazit profil
Re:Dědičnost funkcionálně
« Odpověď #20 kdy: 13. 07. 2018, 16:04:08 »
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

Re:Dědičnost funkcionálně
« Odpověď #21 kdy: 13. 07. 2018, 16:21:10 »
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

Re:Dědičnost funkcionálně
« Odpověď #22 kdy: 13. 07. 2018, 18:46:08 »
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

Re:Dědičnost funkcionálně
« Odpověď #23 kdy: 13. 07. 2018, 18:48:08 »
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

Re:Dědičnost funkcionálně
« Odpověď #24 kdy: 13. 07. 2018, 18:53:54 »
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

  • *****
  • 1 823
    • Zobrazit profil
Re:Dědičnost funkcionálně
« Odpověď #25 kdy: 13. 07. 2018, 20:37:43 »
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

Re:Dědičnost funkcionálně
« Odpověď #26 kdy: 13. 07. 2018, 22:35:40 »
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...  :)