Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
P.S. a jestli můžu už vyloženě vařit z vody, tak předpokládám, že když do typů zavedeš dostatečně silné formule, tak ti tam vznikne nějaký silný jazyk, což bude mít předpokládám dopady do rozhodnutelnosti a tak. Známe to, stačí někam prsknout Peanovu aritmetiku a je průserTypy jsou intuicionistická logika a ta je rozhodnutelná
(Idris mě omluví za humpoláckou mluvu a doupřesní to nebo opraví)
Šlo by tímto způsobem na úrovni typového systému zabránit dělení nulou?Ano, šlo. Je nebetyčná blbost, že by to fungovalo jen s konstantními výrazy, kdo to tvrdí, netuší nic o symbolických výrazech. Ovšem ve složitějším kódu by si to vyžádalo součtové závislostní typy, které jsou “virální” podobně jako zvedání typů pomocí funktorů. Čili technicky to jde a posílí to typovou kontrolu, ale za cenu menší intuitivnosti.
Každé komplexní číslo odpovídá více kvaternionům, musí se prostě zafixovat například j a k, aby byla korespondence jednoznačná. Je to naprosto korektní případ “OO” dědičnosti s veškerými důsledky (podtypy, variance apod.). Kdyby chtěl někdo rýpat, taky může vzít nějaké úchylné vnoření přirozených čísel do reálných a byl by to korektní model. Je by působil bolehlav a WTF uživatelům.U kvaternionů mi to nepřijde zajímavé, ale kdyby to bylo potřeba, šlo by pomocí záv. typů určit konkrétní vnoření. Toto je obecně problém restriktivní dědičnosti (na rozdíl od ampliativní).Vůbec netuším, co má být ta restriktivní a ampliativní dědičnost. Tyhle termíny jsem ještě nepotkal a ani google mi nic užitečného nevrátil. Vztah kvaternionů a komplexních čísel rozhodně není klasické "is".
Minimálně ve 3D grafice je spousta možných konvencí, jak spasovat komplexní čísla a kvaterniony (vidím v nich primárně rotace). Ani jedna z těch konvencí není správnější než ty ostatní. Takže jazyk, typový systém ani knihovny toho nemůžou automaticky moc udělat, protože ani neví, co je správně. Obecně mi v podobných případech přijde jakákoliv automatizace nežádoucí a dobrá akorát jako zdroj zákeřných chyb.
U kvaternionů mi to nepřijde zajímavé, ale kdyby to bylo potřeba, šlo by pomocí záv. typů určit konkrétní vnoření. Toto je obecně problém restriktivní dědičnosti (na rozdíl od ampliativní).Já vidím podobný problém jako při automatickém převodu mezi 2D a 3D vektory. Která rovina ve 3D odpovídá té 2D? Konvencí je mračno a vnutit nějakou na úrovni jazyka mi nepřijde úplně vhodné.Neexistuje kanonické vnoření ℂ do ℍ, ale jinak by tam problém neměl být.Jinak, jaký kvaternion odpovídá komplexnímu číslu? Nemám pocit, že by to šlo úplně jednoznačně překlopit.Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:To mám také na seznamu
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.
A přitom se s tím v jazycích vůbec nesetkávám.
Neexistuje kanonické vnoření ℂ do ℍ, ale jinak by tam problém neměl být.Jinak, jaký kvaternion odpovídá komplexnímu číslu? Nemám pocit, že by to šlo úplně jednoznačně překlopit.Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:To mám také na seznamu
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.
A přitom se s tím v jazycích vůbec nesetkávám.
To nevím, nijak super podrobně jsem to nezkoumal, mohla by to být jedna z cest. Implicitní konverze jsou rozhodně užitečné, jen to teda chce zjistit, co dál je nutné případně přidat.Na tohle by mohly z větší části stačit implicitní konverze, ne?Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:To mám také na seznamu
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.
A přitom se s tím v jazycích vůbec nesetkávám.
Taky by se mi líbila taková jakože obecná dědičnost typů, kdy:To mám také na seznamu
Number > Int > Age > Young
Přičemž by samozřejmě platilo, že jako Int mohu použít Age, ale naopak ne.
A přitom se s tím v jazycích vůbec nesetkávám.
Swift to částečně má, ale protože mají dost omezenou dědičnost, špatně se to tam modeluje správně, abych měl něco jako Quaternion > Complex > Real > ...
Mě by se třeba v jazyce líbilo trochu víc omezení rozsahu typů. Například:Ano, to jsou dependent types. Super věc, jen se špatně implementuje.Kód: [Vybrat]Trochu jsem se shlédl v tom jak to má databáze.function formatName(name: String 1..20, surname: String 1..20)
Pochopil jsem, že toto zřejmě řeší závislostní typy (mimojiné).
To je pravda, ale kdo jim rozumí, občas je využije a šetří to kód.HKT, to jsou obecné konstrukceAle psal jsi, že HKT jsou tak trochu s minimálním efektem...
Kdy vyjde nulta verze jazyka?K tomu ještě dodám, že kdybych někdy náhodou v sobě objevil ambici něco podobného veřejně vydat, šlo by o vylepšení již existujícího a rozšířeného jazyka. Ale momentálně všechen můj čas zabírá výuka a pár projektů na univerzitě a ve spinoffech.
Co tam v tom seznamu máš dál? :-)Dál už to jsou triviální, ale užitečné věci, které už některé jazyky mají, třeba možnost definice vlastních operátorů včetně určení priority a asociativity (tedy mnohem flexibilnější než například v C++) nebo implicitní přetypování (to má C++ a C#). Obecně pozoruju, že v každém jinak poměrně použitelném jazyce něco zásadního chybí. Z toho, co jsem psal, bych na první místo položil ty operátory a HKT, to jsou obecné konstrukce, zbytek už je specifičtější.
Hezký. Co tam v tom seznamu máš dál? :-)Když vynechám poměrně běžné věci, který ale chybí zrovna v tom jazyku, kle to potřebuju, tak to už je poměrně specifické. Jedna věc je mít literály s jednotkami a symbolickým “usuzováním,” abych třeba mohl zapsat číslo jako 1234 kg m s-2 a abych to mohl porovnat s 1234 N, ale ne třeba s 1234 J (tam je totiž m2). To by se hodilo pro (numerické) výpočty ve fyzice. Další rozšíření syntaxe je umožnění zapisování tenzorů (nebo netenzorů, se kterými se počítá jako s tenzory, například Christoffelových symbolů) s kontrolou při překladu (opět obdoba typové kontroly), že indexy jsou správně kontra- či kovariantní. To pak souvisí - na úrovni implementace - s vektorovou implementací atd. S tím souvisí i ty jednotky, všechny komponenty vektoru/tenzoru by měly mít stejnou, takže kromě indexů chci i zajistit shodnost jednotek v (ct,x,y,z) apod. (tj. zařvat, když někdo zapomene c). Prostě věci ze symbolické a numerické matematiky na úrovni, kterou nemají ani specializované jazyky jako R.
To nevyjde, to byla trochu nadsázka. Sice něco existuje a používá se to i v produkci, ale je to in-house a spíš se čeká, až se nějaký mainstreamový jazyk vylepší.Za předpokladu, že je pravdivé tvrzení, že Bůh vědomě způsobil smrt lidem při potopě nebo v Sodomě-Gomoře, tak jaké jsou odpovědi na následující tvrzení?Vsechny ty otazky jsou zalozene na antropomorfizaci Boha a "jeho sveta", coz je hruby omyl. Proto na ne moc nema smysl odpovidat.
S uplne stejnou logikou se muzes ptat, proc Buh zpusobuje to, ze se rodi deti se straslivymi vrozenymi nemocemi. Neni to od nej krute?
Lidsky a bozsky svet jsou proste uplne jine kategorie, nemuzes prenaset meritka z jednoho do druhyho.Právěže to jde i bez DSL.Specificky veci urcite, univerzalni si moc nedovedu predstavit. Ale necham se prekvapit. Kdy vyjde nulta verze jazyka?
Interně možná jako LINQ, ale ten má taky svou extra syntax. Já to chci jako normální lambdu (ono to dokonce pro Javu a C# kdysi bylo, ale ten projekt zanikl).Citace: Idris linke=topic=22043.msg320506#msg320506 date=1573634974Tak ono to není nic světoborného.Idris, neštvi! Koukni v jaké kategorii vlákno skončilo a ty by si mohl poskytnout tak pěkné myšlenky!Citace: Idris linke=topic=22043.msg320506#msg320506 date=1573634974Ale uvedu jeden důležitý případ. Řekněme, že mám objektovou databázi a k ní metodu fetch<T>(T->bool)->[T], která mi má vrátit seznam instancí T, které splňují podmínku danou λ-výrazem, což může být například \person -> person.age >= 18 && person.children.count > 0, prostě libovolný výraz pracující s daty objektu. A teď si představme databázi, kde je objektů chtěného typu miliarda. Asi je zřejmé, že je blbost načítat je z databáze všechny a vyhodnocovat. Takže buď můžu podmínku zapsat jako řetězec a někde bokem rozparsovat (jako s SQL, ale pak překlepy a absence typové kontroly) a použít index, nebo použít nějaký preprocesor, který volání fetch nějak něčím nahradí. Přitom by nebyl problém mít v rámci introspekce (“reflexe”) přístup nejen k datům objektů (to tady taky potřebuju, aby šly objekty uložit do databáze a pak zase poskládat), ale i k ASTu toho výrazu, který mě zajímá. Pak můžu mít přímo v kódu databáze analýzu toho λ-výrazu a použít index, s plnou typovou kontrolou, v rámci jednoho jazyka, bez preprocesorů a skákání na jinou - méně intuitivní - syntax. Když je výraz hodně složitý, může index seznam předfiltrovat a pak se projde a výraz se vyhodnotí (“aspoň něco”). Takto by to bylo plně transparentní a nikdo by se nemusel učit SQL/OQL apod.Hezký.
To zní jako LINQ?
Já jsem si něco takového dělal tak, že jsem vytvářel Expression pomoci objektoveho builderu. Což je sice funkční, ale pěkně hnusný. Tak jsem si ten builder předělal na parser DSLka ze kterého mi vypadl ten samej Expression akorad se to líp zapisovalo.
Matně tuším, že Scala má nějakou podporu pro DSL, takže se to nemusí obchházet přes parsování řetězce.
Chapu tě dobře?
Hezký. Co tam v tom seznamu máš dál? :-)
Právěže to jde i bez DSL.nebo použít nějaký preprocesor, který volání fetch nějak něčím nahradí.Neco podobneho v Elixiru je: https://www.toptal.com/elixir/meet-ecto-database-wrapper-for-elixir - sekce Ecto.Query: vyraz zapsany v Elixiru se automaticky prelozi na SQL.
Trochu blby na tom je, ze skoncis u toho, ze pokud to ma byt univerzalni, stejne budes vytvaret nejaky "SQL-podobny" DSL. Sice to bude ve tvem jazyce (nebudes odskakovat do uplne ciziho SQL), ale nejaky switch tam porad je.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.