Příspěvky

61

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 18:08:13 »

Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.

Konkretizuj to prosím. Představ si, že seš metoda `col`. Na základě čeho uděláš to rozhodnutí, kterou uličkou poslat maticová data?

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

Já bych to asi rozhodoval až v col pomocí isLTE, podle mě to povede ke kratšímu kódu.

No hlavně to bude rozhodovat kompiler, že jo.

62

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 18:07:01 »

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

To je ale specielní případ, kdy jsi funkci `col` inlinoval do volající funkce. Tím ses vyhnul mé otázce, ale tohle není obecné řešení, nemůžeš všude všechno inlinovat. Představ si, že funkce `col` je třeba v už zkompilované knihovně nebo z nějakého jiného důvodu nelze inlinovat.

Za prvé můžu.
Za druhé mě žádný obecný případ nezajímá.
Za třetí, já tvrdím, že se v mnoha, ne-li ve většině případů informacím o typu hodnoty v runtime vyhneš. Ty tvrdíš, že nejenom, že to tam (v runtime) obecně musí být, ale navíc to v některých jazicích být musí (Haskel, Idris) a v některých (Rust) ne.

Mě by zajímalo proč.

63

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 17:55:36 »

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Přijde mi, že tě koncept vtable mate - vtable není typ.

Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Pokud je proveden type-erasure, tak nad tou hodnotou neznám její typ bez ohledu na nic. Takže žádný tag žádný vtable. Prostě to udělat nemlůžu, neznám typ. Nemůžu udělat vidličku nad informací, kterou nemám. Toto si prosím ujasněme.

64

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 17:46:48 »

Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.

Konkretizuj to prosím. Představ si, že seš metoda `col`. Na základě čeho uděláš to rozhodnutí, kterou uličkou poslat maticová data?

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

65

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 17:41:08 »

Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure.

Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.

Tak tak. Ta formulace je blábol, nedává to vůbec smysl.

A byl by nějaký argument? Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.

To ale není argument.
Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.
Pokud typy (v run-time) používám, tak neprovedu type erasure, a pak tam ty typy někde musím mít. Třeba jako vtable ¹⁾, abych se mohl dotázat, jaký typ má tato hodnota když tu informaci o typu potřebuji.
Situaci, kdy může být uchování typu hodnoty až do runtime zajímavé jsem uváděl v předchozím příspěvku.

Mě přijde, že to chápeš přesně opačně než jak to je :-)

¹⁾ Samozřejmě název vtable je zavádějící, protože to se používá v jiném kontextu u C++, ale ty sis začal.

66

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 17:34:15 »

Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly.

Jak jsi poznal, že tam nebyly typové informace? V jazyce jako Lua má každá hodnota runtime typovou informaci, tak fungují dynamicky typované jazyky, tzn. ty typy tam nemohly nebýt

Na vstupu bylo x = Red. V lue bylo x = 1. To považuji, že tam ten Red není.

Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure.

Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Dobře, tak mějme ten příklad s maticí. Dejme tomu, že od nějaké velikosti Thr (jako threshold) používá implementace matice nějakou vymakanou reprezentaci v paměti kvůli ušetření místa pro velké matice. Ok? Teď dejme tomu, že máme operaci `col` na matici, která vrátí daný sloupec jako vektor. Tahle operace bude muset fungovat různě v závislosti na Thr, z úsporné reprezentace se čte sloupec jinak než z jednoduché.

Tak, a teď, ty napíšeš program, který načte matici ze souboru a bude chtít číst sloupce. Pokud by ta typová informace - v tomto případě velikost matice - byla komplet odstraněna, metoda `col` by neměla jak poznat, jak je konkrétní matice v paměti reprezentována, a tedy jak extrahovat sloupec. Proto bude muset ta matice si s sebou tu informaci vzít a držet si ji během runtime, buďto to může být nějaký tag, podle kterého udělá ta metoda `col` vidličku, anebo si s sebout vezme vtable, která bude u různých konkrétních hodnoty ukazovat na různé implementace `col`. Řešení s vtable je obecnější - těch typových parametrů může být více, chování se může v závislosti na nich více lišit.

V jazyce jako Rust nebo C++ tohle není potřeba, protože kompilátor zná dopředu všechny instanciace a provede monomofrizaci, ie. v podstatě z toho udělá různé typy s různými metodami, ale cena za to je, že není možné vytvořit tu hodnotu at runtime.

Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.

V tomto případě tam nikde není třeba uchovávat informaci o typu, ani v tagu, ani nikde.

Ale budiž, blbej případ.

Problém není v tom, že by informace nemohla být v runtimu, že by tam nemohl být nějaký tag, nebo co já vím. Ty tvrdíž, že tam být musí, zatímco v Rustu být nemusí. Ale vůbec mi nedochází, kde to musení vidíš.

Představ si lepší překlad:

Kód: [Vybrat]

type Matice a = GenericMatice a | OptimalizedMatice a
let xs : [Matice] = parseFromFile(f)

out = map format xs
where
   format x = case (type x):
      GenericMatice m -> formatGenericMatice m
      OptimalizedMatice m -> formatOptimalizedMatice m

Toto je první příklad, kde by mě napadlo, že by se hodilo type erasured nemít. A určitě se shodnem, že to některé jazyky takto můžou, přidat tam ty tagy, použít. Jiné jazyky něco takové zakážou. A některé jazyky (nebo ty samé, ale prostě si usmysleli) to zoptimalizují tak, že tam budou dvě "uličky" (v tomto případě si to nedokážu úplně představit, ale to není argument - stejně tak nedokážu najít "důkaz", proč by to nemělo jít). Pak tam v rámci optimalizace nebude vůbec žádná informace o typu.

67

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 16:28:44 »

Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure.

Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.

68

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 16:22:09 »

Ano, ta typová kontrola probíhá při překladu, to já nijak nerozporuju, ale ten vygenerovaný kód, který je produktem toho kompilátoru, musí pak nutně záviset na runtime vlastnostech. ... ale jakmile bude to bude složitější, nepůjde to.

Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.

Já mam na mysli tu situaci, kdy zkonstruuješ parametrizovaný typ jako např. ten vektor nebo matici dynamicky ze vstupních dat. Lua úplně není dobrej příklad, protože to je dynamicky typovaný jazyk, tj. pochopitelně obsahuje runtime typové informace. Spíš by bylo lepší se podívat na ten C výstup.

C je bordel na kolečkách. S tím se odmítám zabejvat.

Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly. Prostě Amulet vzal ty typové informace, provedl z toho transformaci na Luu, a všechny ostatní věci zahodil.

Co se týče toho vtable, na které jsi narážel - tomu se mi nechce věřit. To je nějaké matení. Protože:
1/ Jistě, Haskell má své hranice, a některé věci prostě už neutáhne compiletime, a tak se ty věci, které nejdou, převedou do runtime - v tomto samozřejmě souhlas.
2/ Cílem je, abychom dosáhli situace, kdy všechny věci budou podchyceny v compiledtime. Viz Idris.
3/ Výsledný kód nemusí nutně záviset na runtime - to je to tvrzení, které rozporuji.
4/ Já se neodvažuji tvrdit, zda borrowing je otázka typu nebo ne. Ale každopádně si představuji, že když dám v Rustu x.get_borrow() tak mi to může udělat různé věci. Od nějaké lokální proměnný, kde bude uchovanej výsledek, přes volání nějaké runtime obsluhy. Nic není daný musem.
5/ Samozřejmě, nikde nic nemusí být boxované, nebo boxovatelné.

69

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 16:10:59 »

Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. […] Já tě jinak chci vyprovokovat, třeba něco napsat :-)

Myslím, že kdysi jsme se bavili o pokročilých typech na příkladu definice sudosti na úrovni typů. Ten příslušný typ “IsEven” je vlastně taky GADT, klidně to můžeme rozebrat znova z tohoto úhlu, jestli si myslíš, že to bude pro tebe přínosné.

Mám o to zájem, a předem děkuji.

Už si bohužel nepamatuju, jak daleko jsme se tehdy dostali, ale opakování matka moudrosti

Dost mi to dalo, ale jak říkáš. Hlavně jsme se točily kolem forall, to bylo v tu dobu pro mě hodně zajímavé.

Typ IsEven má (meta)typ Nat -> Type (je to tedy typový konstruktor), v podstatě je to "funkce" (funkce na úrovni typů), která dostane přirozené číslo (Nat je induktivní typ, to teď asi není důležité) a vrátí typ. Potud asi jasné (?). Hlavička definice tedy bude

Kód: [Vybrat]

data IsEven : Nat -> Type where

Tento typ má dva konstruktory, řekněme ZIsEven a SuccSuccIsEven, které generují hodnoty různých typů (proto se jedná o GADT), ten první je typu IsEven 0 a ten druhý typu IsEven (n+2) pro nějaké přirozené číslo n.

Typ chovající se jako funkce. Tomu rozumím. Jak se to liší a v čem je to podobné proti průmyslovým generikám:

Kód: [Vybrat]

type IsEven<T>

případně:

Kód: [Vybrat]

type IsEven<T> where T is Nat

?

70

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 16:02:11 »

Ano, ta typová kontrola probíhá při překladu, to já nijak nerozporuju, ale ten vygenerovaný kód, který je produktem toho kompilátoru, musí pak nutně záviset na runtime vlastnostech. ... ale jakmile bude to bude složitější, nepůjde to.

Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.

71

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 22:50:06 »

Pred 10 000 rokmi ale ludia hovorili inymi jazykmi, ak vobec nejake mali, ak to neboli (pre nas z dnesneho pohladu) iba nejake pazvuky, hmkanie, mlaskanie a co ja viem co dalsie.

Navzdory tomu, že té argumentaci rozumím a souhlasím, a abych si udržel špatnou pověst, tak si neodpustím rejp: Není jediný důkaz toho, že by se jazyky vyvíjeli. Když porovnáš nejstarší jazyk Egyptštinu a porovnáš s libovolným moderním jazykem, tak jsou tam sice změny, ale ne kvalitativní (něco se sofistikuje, něco se zjednodušuje). Tvrzení, že na začátku bylo mlaskání a krkání je tvrzení založené na tom, že to tak přece muselo být.

72

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 20:07:40 »

Pokud jde o nutnost memory safe jazyku, s tim nepolemizuju, akorat stale nejsem presvedcen, ze cesta je prave pres Rust.

Pokud si jako kritérium vezmeš memory safe, tak ačkoliv Rust není dokonalý, tak čím by si mu chtěl konkurovat? (Bavíme se o nízkoúrovňovém jazyku. Na nějaké appky vždycky můžeš použít Javu, samozřejmě.) Jaké máš výhrady, nebo očekávání?

73

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 10:32:01 »

Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.

Carbon v Google vzniknul primárně ze dvou důvodů:

• Bezpečnost C++ je hrozná, Carbon tohle (částečně) řeší.
• C++ steering committee dlohodobě ignorovala snahy Google o rozbití ABI, což Google považuje za nutné k dalšímu rozvoji C++ (tady jsem na straně Google).

Carbon je zajímavý počit, ale jedním z jeho primárních cílů byla dobrá interoperabilita s existujícím C++ kódem, což dost omezuje při návrhu jazyka, nemohli to prostě udělat celé od základu jinak (jak to udělal třeba Rust). Google má spoustu existujícího kódu v C++ a nemůže si dovolit všechno zahodit a přepsat, proto potřebuje jazyk, ze kterého půjde volat existující C++ kód. Důsledem je, že Carbon v součané podobě není memory safe. Někdy možná bude, ale vyžádalo by si to zpětně nekompatibilní změny v designu jazyka. Takže pocity z Carbonu jsou zatím spíš rozpačité, oproti C++ je to posun vpřed, ale zároveň je to takové polovičané řešení, primárně kvůli požadavku na interoperabilitu s C++.

Když to porovnáš s Dlang? Lepší, horší, jiné?

74

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 10:25:13 »

Tady ale nešlo o vysvětlování, ale porovnání jazyků, ne? Na to jsem reagoval. Jinak samozřejmě ano, určitě je žádoucí mít někde polopatický popis GADT apod. Na ten úvod do Haskellu by šlo asi plynule navázat.

Jde o to, že když ti číňan, když už si půjčíme to otřepané přirovnání, začne čínsky vysvětlovat, že oni by to řekli takhle hezky... Dokavad neumíš čínsky, tak to neoceníš, a když už umíš čínsky, tak to nepotřebuješ.

Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. Taky hodně zhruba vím, co to to GADT je (spíše méně, než více). A přesto mi ten tvůj příklad vůbec k ničemu nebyl. To jsi chtěl?

Jinak samozřejmě ano, určitě je žádoucí mít někde polopatický popis GADT apod. Na ten úvod do Haskellu by šlo asi plynule navázat.

Já tě jinak chci vyprovokovat, třeba něco napsat :-)

75

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 02:05:40 »

Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.

U HKT je situace asi celkem jasná (aplikativní funktory a tak). U GADT je to zajímavější, umožní mi mít například toto:

Kód: [Vybrat]

data Vect : (len : Nat) -> (elem : Type) -> Type where
  Nil  : Vect Z elem
  (::) : (x : elem) -> (xs : Vect len elem) -> Vect (S len) elem

Podobně se dají udělat matice s dimenzí na úrovni typů. Navíc ty dimenze nemusí být známy v době překladu, klidně se můžou načíst ze vstupu/souboru. Tohle bez GADT nejde. Porovnání s C++, Javou nebo Rustem prostě je, že v těchto jazycích dimenze staticky ověřovat nejde (například při skalárním součinu nebo násobení matic).

Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý.

Všichni nejsou blbí. Pro ty úplně blbé to psát nebudu, vždy se předpokládá určitá znalost, na které lze stavět (třeba co je konkrétní typ — “Int”, “List Int” a “Int -> Int” jsou konkrétní kupříkladu). Nejsme ve školce.

Tohle znáš? http://naucte-se.haskell.cz/kapitoly

Lidi jsou blbý. Kolika profesionálním ¹⁾ programátorům jsem vysvětloval, co je to rozhraní a k čemu je to dobrý.

Buď jsi elitář ²⁾, a nebo chceme, aby ty jazyky používali lidi v průmyslu.


1) Profesionální znamená, že se tím živili.
2) Nikdo tě samozřejmě nenutí, aby si to vysvětloval zrovna ty, pokud se ti nechce. Ale vysvětlovat jak ve školce je třeba, sorry jako.