Funktory v C++

[zboj]

Určitě, ale měl by vědět, že to je jenom (velmi dobrý) způsob, jak si to představit, ne že to "je ono".

Nekritizoval tě tu někdo v nějakém jiném vlákně za něco podobného?   

Funkce není funktor ve smyslu otázky ani s nimi nemá nic společného.

Ale ve smyslu otázky to je. Spíš bych řekl, že odpověď ve smyslu category theory nebyla smyslem otázky. Jako jasně, můžeme se začít bavit o endofunktorech, morfismech apod., ale nakonec stejně skončíme s tím, že prakticky vzato je to (v drtivé většině využítí) kontejner a jako zajímavost, function object, který vrací T je funktor taky (a že se na to, svým způsobem, taky dá dívat jako na kontejner).

Otázka byla zcela zjevně o konceptu z teorie kategorií. Ale na druhou stranu je dobře, že se aspoň vyjasnila terminologie (včetně toho Prologu, tam to je fakt na přesdržku  ).

[Reklama]

[Mirek Prýmek]

Nekritizoval tě tu někdo v nějakém jiném vlákně za něco podobného?   

Ne, za přesně opačnou věc

a jako zajímavost, function object, který vrací T je funktor taky (a že se na to, svým způsobem, taky dá dívat jako na kontejner).

Functor může být cokoli, když si kategorie nadefinuješ tak, aby byly splněna ta definice, co jsi psal. Ale v tom běžném chápání, jak je v Haskellu ("kategorie Hask"), jsou funkce morfismy. Viz https://en.wikibooks.org/wiki/Haskell/Category_theory#Functors_on_Hask

Translating categorical concepts into Haskell
Functors provide a good example of how category theory gets translated into Haskell. The key points to remember are that:

We work in the category Hask and its subcategories.
Objects are types.
Morphisms are functions.
Things that take a type and return another type are type constructors.
Things that take a function and return another function are higher-order functions.
Typeclasses, along with the polymorphism they provide, make a nice way of capturing the fact that in category theory things are often defined over a number of objects at once.

[zboj]

Nekritizoval tě tu někdo v nějakém jiném vlákně za něco podobného?   

Ne, za přesně opačnou věc

a jako zajímavost, function object, který vrací T je funktor taky (a že se na to, svým způsobem, taky dá dívat jako na kontejner).

Functor může být cokoli, když si kategorie nadefinuješ tak, aby byly splněna ta definice, co jsi psal. Ale v tom běžném chápání, jak je v Haskellu ("kategorie Hask"), jsou funkce morfismy. Viz https://en.wikibooks.org/wiki/Haskell/Category_theory#Functors_on_Hask

Translating categorical concepts into Haskell
Functors provide a good example of how category theory gets translated into Haskell. The key points to remember are that:

We work in the category Hask and its subcategories.
Objects are types.
Morphisms are functions.
Things that take a type and return another type are type constructors.
Things that take a function and return another function are higher-order functions.
Typeclasses, along with the polymorphism they provide, make a nice way of capturing the fact that in category theory things are often defined over a number of objects at once.

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

[BoneFlute]

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

To možná jo, ale přijde mi výstižnější. V Haskellu je typ type, a třída class. V javě se typu říká class a třídám interface. A v C++ je to ještě zajímavější.

[Mirek Prýmek]

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

Co máš namysli?

[Reklama]

[zboj]

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

To možná jo, ale přijde mi výstižnější. V Haskellu je typ type, a třída class. V javě se typu říká class a třídám interface. A v C++ je to ještě zajímavější.

No jo, v Javě a C++ apod. to už je terminologie OOP (přiohnutá). Já myslel jen v kontextu FP.

[zboj]

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

Co máš namysli?

Tak třeba že jedné části funktoru se říká "typový konstruktor" a druhé "fmap", to nejen že nemá oporu jinde (je to vycucané z prstu), ale navíc to svádí k domněnce, že jde o dvě různé věci.

[Mirek Prýmek]

Tak třeba že jedné části funktoru se říká "typový konstruktor" a druhé "fmap", to nejen že nemá oporu jinde (je to vycucané z prstu), ale navíc to svádí k domněnce, že jde o dvě různé věci.

No jo no, tak to je asi daný tím, že tu první část (mapování objektů) máš už v "hlavičce"

Kód: [Vybrat]

class Functor (f :: * -> *) where
...čili Functor v Haskellu je jeden konkrétní funktor (Hask -> neco Hask).

Kdyby měl být Functor jakýkoli obecný functor, tak už by tomu asi nerozuměl vůbec nikdo, když už i takhle s tím lidi mají problémy Člověk to musí brát tak, že Haskell nemá modelovat CT v její obecnosti, ale jenom ji využívá pro jeden konkrétní účel...

[zboj]

Tak třeba že jedné části funktoru se říká "typový konstruktor" a druhé "fmap", to nejen že nemá oporu jinde (je to vycucané z prstu), ale navíc to svádí k domněnce, že jde o dvě různé věci.

No jo no, tak to je asi daný tím, že tu první část (mapování objektů) máš už v "hlavičce"

Kód: [Vybrat]

class Functor (f :: * -> *) where
...čili Functor v Haskellu je jeden konkrétní funktor (Hask -> neco Hask).

Kdyby měl být Functor jakýkoli obecný functor, tak už by tomu asi nerozuměl vůbec nikdo, když už i takhle s tím lidi mají problémy Člověk to musí brát tak, že Haskell nemá modelovat CT v její obecnosti, ale jenom ji využívá pro jeden konkrétní účel...

Já tu motivaci chápu, ale je to matoucí pro lidi, co do toho vidí do hloubky. Možná to je kompromis mezi "uděláme to přesně do puntíku superformálně matematicky" a "uděláme to nějak tak jakž takž, aby to pobral i Pepa, co sedí za rohem v Lidlu za kasou". Jenže v prvním případě to je pak dost nepřesné a v tom druhém to stejně nakonec skončí přidáváním různých epicyklů, takže to stejně skončí jako složitost. Nedávno (tebou) zmíněný Prolog mimochodem dtto, vyjde se z jednoduché a jasné (a jasně a přesně už dříve nezávisle na konkrétním použití formulované) myšlenky a skončí to kočkopsem s hromadou vlastních výjimek (a vlastní terminologií).

[Mirek Prýmek]

Já tu motivaci chápu, ale je to matoucí pro lidi, co do toho vidí do hloubky. Možná to je kompromis mezi "uděláme to přesně do puntíku superformálně matematicky" a "uděláme to nějak tak jakž takž, aby to pobral i Pepa, co sedí za rohem v Lidlu za kasou". Jenže v prvním případě to je pak dost nepřesné a v tom druhém to stejně nakonec skončí přidáváním různých epicyklů, takže to stejně skončí jako složitost. Nedávno (tebou) zmíněný Prolog mimochodem dtto, vyjde se z jednoduché a jasné (a jasně a přesně už dříve nezávisle na konkrétním použití formulované) myšlenky a skončí to kočkopsem s hromadou vlastních výjimek (a vlastní terminologií).

No jo, jenže se prostě bavíme o programovacích jazycích, kde primární motivace je vytvořit něco, v čem se dá dobře programovat a ne něco, co supervěrně modeluje matematickou teorii. Dovedeš si představit, jak by ten formálně přesný functor mohl vypadat?

Kód: [Vybrat]

mapObject : ??? -> ???
mapMorphism : ??? -> ???
...kde

Kód: [Vybrat]

??? by mohlo být úplně cokoli... To by asi byla pěkná makačka na bednu nějak to smysluplně definovat a ještě ke všemu pro to napsat překladač

U toho Prologu je to imho podobně - zjistilo se, že pro praktické generické použití ten jednoduchý model nestačí a šup, je potřeba tam přidat různý specialitky Osobně mi to taky sympatický není, kdyby Prolog zůstal jenom jako "dotazovací jazyk" (podobně jako Datalog) a nedělal se z něho generický programovací jazyk (který pak stejně máo kdo umí dobře použít), přišel by mi sympatičtější.

[zboj]

Já tu motivaci chápu, ale je to matoucí pro lidi, co do toho vidí do hloubky. Možná to je kompromis mezi "uděláme to přesně do puntíku superformálně matematicky" a "uděláme to nějak tak jakž takž, aby to pobral i Pepa, co sedí za rohem v Lidlu za kasou". Jenže v prvním případě to je pak dost nepřesné a v tom druhém to stejně nakonec skončí přidáváním různých epicyklů, takže to stejně skončí jako složitost. Nedávno (tebou) zmíněný Prolog mimochodem dtto, vyjde se z jednoduché a jasné (a jasně a přesně už dříve nezávisle na konkrétním použití formulované) myšlenky a skončí to kočkopsem s hromadou vlastních výjimek (a vlastní terminologií).

No jo, jenže se prostě bavíme o programovacích jazycích, kde primární motivace je vytvořit něco, v čem se dá dobře programovat a ne něco, co supervěrně modeluje matematickou teorii. Dovedeš si představit, jak by ten formálně přesný functor mohl vypadat?

Kód: [Vybrat]

mapObject : ??? -> ???
mapMorphism : ??? -> ???
...kde

Kód: [Vybrat]

??? by mohlo být úplně cokoli... To by asi byla pěkná makačka na bednu nějak to smysluplně definovat a ještě ke všemu pro to napsat překladač

Já ale nekritizuju, jak to je udělané v kódu, jen jsem kritizoval terminologii. Je jasné, že v implementaci vždy budou kompromisy a zjednodušení.

[Mirek Prýmek]

Já ale nekritizuju, jak to je udělané v kódu, jen jsem kritizoval terminologii. Je jasné, že v implementaci vždy budou kompromisy a zjednodušení.

Takže by ti v podstatě stačilo, kdyby se typovému konstruktoru říkalo nějak jako "the object-mapping functor part". Tak ti nevím

[zboj]

U toho Prologu je to imho podobně - zjistilo se, že pro praktické generické použití ten jednoduchý model nestačí a šup, je potřeba tam přidat různý specialitky Osobně mi to taky sympatický není, kdyby Prolog zůstal jenom jako "dotazovací jazyk" (podobně jako Datalog) a nedělal se z něho generický programovací jazyk (který pak stejně máo kdo umí dobře použít), přišel by mi sympatičtější.

Tak to je právě ten problém, ono to není pro "praktické generické" použití, motykou taky nekácím strom, i když by to nějak vyďoubat třeba šlo. Prolog má sílu pro dedukci, nejlépe s nějakým doplňkem pro nonfloundering teorie (jinak to je taky dost nedostatečné). Dělat v tom GUI a jánevímco je jako dělat GUI v SQL. Nicméně opět, nešlo mi o čistotu Prologu, jen o terminologii (tady za to může Kowalski).

[Mirek Prýmek]

je jako dělat GUI v SQL

Jo, to je dobrý přirovnání

[zboj]

Já ale nekritizuju, jak to je udělané v kódu, jen jsem kritizoval terminologii. Je jasné, že v implementaci vždy budou kompromisy a zjednodušení.

Takže by ti v podstatě stačilo, kdyby se typovému konstruktoru říkalo nějak jako "the object-mapping functor part". Tak ti nevím

To je zrovna jen další výmysl ("když je bordel v terminologii, uděláme úplně novou" ). Matematicky to je "functor restricted on (the category of types') objects". V matematice se ostatně často může říct jen "funktor", když ta restrikce plyne z kontextu (což většinou plyne, a když ne, tak se to upřesní). Podobně, proč se používá "fmap" (to je možná ještě horší, protože "type constructor" je aspoň výstižné)?