Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Prograt 17. 02. 2018, 22:08:16

Název: Conditional conformance v OOP
Přispěvatel: Prograt 17. 02. 2018, 22:08:16
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
Název: Re:Conditional conformance v OOP
Přispěvatel: Sten 17. 02. 2018, 22:38:41
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 18. 02. 2018, 01:32:39
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 18. 02. 2018, 01:44:28
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.
Go taky nemá pravé duck typing (pročež je bezpečné a staticky typované). Ta podmíněná konformita akorát umožňuje flexibilnější a úspornější implementaci protokolů u generických typů (ať už tříd nebo struktur). Ovšem bez higher kinds (viz "vyšší druhy" na Wikipedii) bude typový systém Swiftu stále neúplný.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 18. 02. 2018, 07:08:20
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.

Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 18. 02. 2018, 12:57:39
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.

Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
Duck typing je záležitost běhu (runtime), kdežto v Go se všechny typy řeší při kompilaci, je to normální statické typování s rozhraními. Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.
Název: Re:Conditional conformance v OOP
Přispěvatel: Bach 18. 02. 2018, 20:25:22
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.
Název: Re:Conditional conformance v OOP
Přispěvatel: adsfasdfasdfasdf 18. 02. 2018, 22:16:35
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.

ale ma to logiku, zkompiluje se jen to co se pouzije.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 19. 02. 2018, 03:28:52
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.

HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?

Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.

Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.

Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 19. 02. 2018, 03:50:04
Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 19. 02. 2018, 04:01:18
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.

HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?

Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.

Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.

Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).

K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 19. 02. 2018, 04:59:16
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 19. 02. 2018, 05:10:21
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 19. 02. 2018, 05:29:21
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).

Tak jo, nesledoval jsem to zas tak bedlivě, takže jestli to opravili, tím líp. Řeší to i známý bug, kdy GC neuvolňoval kanál, na který čekala gorutina, po té, co skončil producer?

K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.

To není pravda. Příklad:

Kód: [Vybrat]
func main() {
        c := make(chan string)
        go func() {
                msg := <- c
                fmt.Println(msg)
                c <- "hello"
        }()

        msg := <- c
        fmt.Println(msg)
        c <- "world"
}

Žádné chybové hodnoty nikde nejsou, přeloží se to v pohodě bez warningů, ale zkuste si to pustit. Bum.

NB: v Rustu se stejný program ani nepřeloží, protože vede k typové chybě, kterou kompiler detektuje.
Název: Re:Conditional conformance v OOP
Přispěvatel: klokan 19. 02. 2018, 05:34:19
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

Jakže děláte HKT v C++? To by mě docela zajímalo.
Název: Re:Conditional conformance v OOP
Přispěvatel: n 19. 02. 2018, 07:40:01
https://stackoverflow.com/questions/2565097/higher-kinded-types-with-c
Název: Re:Conditional conformance v OOP
Přispěvatel: andy 19. 02. 2018, 09:46:14
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
Název: Re:Conditional conformance v OOP
Přispěvatel: v 19. 02. 2018, 11:07:28
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
jako že "instance (A b) => A (C b)"?
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 19. 02. 2018, 13:01:00
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

Jakže děláte HKT v C++? To by mě docela zajímalo.
Částečnou specializací šablon. Jdou tak napsat generické monády. Spíš jsem si jen hrál, když jsem to chtěl v C++ napsat haskellím stylem. Inspirací byl článek o F-algebrách v C++.
Název: Re:Conditional conformance v OOP
Přispěvatel: andy 19. 02. 2018, 13:12:29
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
jako že "instance (A b) => A (C b)"?
Přesně.
Název: Re:Conditional conformance v OOP
Přispěvatel: Labrat 19. 02. 2018, 13:26:47
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
Ono nejen ta konformance, celý koncept extensions je velmi mocný, protože umožňuje vzít jakýkoliv typ a rozšířit ho pro libovolný protokol bez dědění. A to vše s typovou kontrolou při překladu.
Název: Re:Conditional conformance v OOP
Přispěvatel: 10xCoder 19. 02. 2018, 17:54:01
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

Jakže děláte HKT v C++? To by mě docela zajímalo.
V C++ přece může být parametrem šablony šablona, což je přesně definice HKT. Žádná hluboká věda v tom není a vůbec nemusíme zmiňovat fujmonády :)
Název: Re:Conditional conformance v OOP
Přispěvatel: n 19. 02. 2018, 19:42:18
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

Jakže děláte HKT v C++? To by mě docela zajímalo.
V C++ přece může být parametrem šablony šablona, což je přesně definice HKT. Žádná hluboká věda v tom není a vůbec nemusíme zmiňovat fujmonády :)

jj, jak jsem pastnul vyse: https://stackoverflow.com/questions/2565097/higher-kinded-types-with-c
kde je teda sice zrovna priklad monady, ale whatever... :)
templatama se da v c++ napsat vsecko, i kdyz teda pro nezkuseneho je to dost tezce citelne :) ..ale zas pouziti uz muze byt celkem pekne...
Název: Re:Conditional conformance v OOP
Přispěvatel: Idris 19. 02. 2021, 22:25:18
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Tohle je sice hodně zrezivělé (pun intended) vlákno, ale ať je to v kontextu: Rust už HKT má.
Název: Re:Conditional conformance v OOP
Přispěvatel: Baloun 20. 02. 2021, 09:01:29
Jestli tomu dobře rozumím, tak to je jako koncepty v C++20. Což je v podstatě jen syntaxe pro SFINAE, který se v C++ používá od doby zavedení šablon.
Název: Re:Conditional conformance v OOP
Přispěvatel: okalousek 20. 02. 2021, 09:39:23
Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Rust používá monády a má na nich postaven systém řešení chyb. Nemyslím si že jsou monády nepochopitelné, není to zrovna nic dvakrát složitého.
Název: Re:Conditional conformance v OOP
Přispěvatel: Idris 20. 02. 2021, 12:41:13
Jestli tomu dobře rozumím, tak to je jako koncepty v C++20. Což je v podstatě jen syntaxe pro SFINAE, který se v C++ používá od doby zavedení šablon.
V Rustu to je přes přifařené typy. Jenže ty původně nebyly generické, takže nešlo implementovat HKT. Teď už jsou, takže to už jde.