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říspěvky - Idris

Stran: 1 ... 147 148 [149] 150 151 ... 153
2221
Díky, homebrew už mám a macports, fink prozkoumám.
Používate pro terminal tu základní app co je v systému nebo něco "lepšího" z appstoru ?
Mac
Já tu základní, bohatě stačí.

2222
Odkladiště / Re:Vyplatí se koupit iPhone 6S?
« kdy: 02. 05. 2018, 19:53:50 »
Kde se vzal ten mýtus, že bez iTunes se iPhone nedá používat? Já sice nejsem příznivcem iPhonu, sám ho nepoužívám, i když bych ho mohl nafasovat, ale většina lidi, co znám, používá iTunes jako naprosto autonomní zařízení a o iTunes nepoužívají.

Chces rici, ze na ajFoun dneska dostanes hudbu prostym nakopirovanim
Prostým zakoupením přímo na telefonu ;)

2223
Odkladiště / Re:Vyplatí se koupit iPhone 6S?
« kdy: 02. 05. 2018, 12:04:46 »
Ještě se oficiálně prodává, tak bych se toho nebál, bude mít plnou podporu ještě přinejmenším dva roky po datu, kdy ho přestanou prodávat, spíš tři (soudě dle podpory starších modelů dříve).

2224
Vývoj / Re:Curryfikované funkce v Haskellu
« kdy: 02. 05. 2018, 00:17:42 »
Takže ve výsledku funkce s libovolným počtem parametrů, která vrací Monoid, je Monoid.
To se mi nezdá. Funkce s libovolným počtem parametrů bude Monoid jen po ruční curryfikaci. Automaticky ne.
funkce s libovolným počtem argumentů je funkce s jedním argumentem kde výsledek je funkce s libovolným počtem argumentů minus jedna :)
a0 -> a1 -> ... an -> t
je jako
a0 -> t' kde t' = (a1 -> ... -> an -> t)
nebo taky
a0 -> (a1 -> ... an -> t)
Ha! Rozumím.
Ještě doplním, že v signaturách typů je typový operátor → zprava asociativní, takže a→b→c znamená, chceme-li být zcela přesní, a→(b→c) a ta curryfikace v podstatě formálně znamená, že ke každé funkci typu a→b→c existuje isomorfní funkce typu a×b→c (ty funkce nejsou formálně stejné, i když v konkrétní implementaci můžou být identické).

2225
Vývoj / Re:Formální verifikace podle typu na rozsah
« kdy: 02. 05. 2018, 00:06:59 »
To Str.sub bude mít svůj návratový typ, a pokud ten není podtypem návratového typu té vnější funkce, překladač zařve.
Tak v tom případě to není odpověď na mou otázku :-)

Str.sub vrací String 0 ∞, zatímco fn vrací String 4 20. Takže mi to může vrátit dvouznakový řetězec, a to už je špatně.

A přesto očekávám, že (v případě, když bych tam neměl tu záměrnou chybu) mi to překladač označí za korektní.
No ale přece String 0 ∞ není podtypem String 4 20, tady je ta kontrola ještě přímočará. Možná teda nejspíš nechápu otázku. BTW to Str.sub by mělo mít návratový typ také závislostní podle vstupních parametrů, jinak by byla typová kontrola příliš restriktivní.

Počkej, počkej, mám pocit, že jsme se tu někdo z nás ztratil.

Str.sub má návratový typ String 0 ∞. Takže může vrátit dvouznakový řetězec. Vstupní argumenty jsou 20, což je ok na výstup, takže tento argument změní návratový typ na String 0 20. A dále String, jehož minimální velikost je určena tou kontrolou v if. Což je tedy defakto taky správně, a ta funkce bude pracovat korektně. A já se tedy táži, jak typový systém pozná, že díky podmínce if se z hodnoty String 0 20 stane hodnota typu String 2 20 (respektive String 4 20).

Zdůrazňuji, že já se táži na typový systém, který řeší mou úlohu. Netáži se jak fungují závislostní typy (i když zrovna třeba ony mohou řešit mou úlohu, a pak mě zajímá jak to řeší).
Jo, teď jsem se už definitivně ztratil já :( Co je myšleno tím "změnit návratový typ"?

2226
Vývoj / Re:Formální verifikace podle typu na rozsah
« kdy: 01. 05. 2018, 22:40:31 »
To Str.sub bude mít svůj návratový typ, a pokud ten není podtypem návratového typu té vnější funkce, překladač zařve.
Tak v tom případě to není odpověď na mou otázku :-)

Str.sub vrací String 0 ∞, zatímco fn vrací String 4 20. Takže mi to může vrátit dvouznakový řetězec, a to už je špatně.

A přesto očekávám, že (v případě, když bych tam neměl tu záměrnou chybu) mi to překladač označí za korektní.
No ale přece String 0 ∞ není podtypem String 4 20, tady je ta kontrola ještě přímočará. Možná teda nejspíš nechápu otázku. BTW to Str.sub by mělo mít návratový typ také závislostní podle vstupních parametrů, jinak by byla typová kontrola příliš restriktivní.

2227
Vývoj / Re:Formální verifikace podle typu na rozsah
« kdy: 01. 05. 2018, 18:42:12 »
To jsou závislostní typy, verifikace se dělá přes theorem proving (takže překlad programu někdy trvá hodiny). Viz například jazyk Idris.
Mohl by si prosím lidsky popsat princip, jak se ta verifikace dělá?
Jako normální typová analýza, akorát typové operátory (konstruktory) berou i hodnoty krom typů. Třeba append na řetězcích by měl typ "String n m -> String k l -> String (n+k) (m+l)", takže v rámci typové kontroly (tj. během překladu, ne až za běhu) se počítá, v tomto případě s přirozenými čísly. Musí se dávat pozor na subsumpci a varianci, třeba String n m je podtypem String k l, pokud n>=k & m<=l.
Díky.
Uniká mi v tvé odpovědi, jak ten systém pozná, že Str.sub s 20 ve větvi else vrátí vždy korektní minimální čtyři znaky. (Tedy v mém případě pozná, že nevrátí, a tudíž nahlásí chybu.)
To Str.sub bude mít svůj návratový typ, a pokud ten není podtypem návratového typu té vnější funkce, překladač zařve.

2228
Vývoj / Re:Formální verifikace podle typu na rozsah
« kdy: 01. 05. 2018, 04:29:20 »
To jsou závislostní typy, verifikace se dělá přes theorem proving (takže překlad programu někdy trvá hodiny). Viz například jazyk Idris.
Mohl by si prosím lidsky popsat princip, jak se ta verifikace dělá?
Jako normální typová analýza, akorát typové operátory (konstruktory) berou i hodnoty krom typů. Třeba append na řetězcích by měl typ "String n m -> String k l -> String (n+k) (m+l)", takže v rámci typové kontroly (tj. během překladu, ne až za běhu) se počítá, v tomto případě s přirozenými čísly. Musí se dávat pozor na subsumpci a varianci, třeba String n m je podtypem String k l, pokud n>=k & m<=l.

2229
Vývoj / Re:curryfikované funkce
« kdy: 01. 05. 2018, 01:23:47 »
Jo, je to detail, v podstatě se tím jen lidsky říká, že typový systém je kartézsky uzavřený, tj. v jistém smyslu úplný (má součinové, součtové a exponenciální typy).

2230
Vývoj / Re:Formální verifikace podle typu na rozsah
« kdy: 01. 05. 2018, 01:19:11 »
To jsou závislostní typy, verifikace se dělá přes theorem proving (takže překlad programu někdy trvá hodiny). Viz například jazyk Idris.

2231
Vývoj / Re:Nový objev ve funkcionálním programování
« kdy: 24. 04. 2018, 00:55:40 »
Prymku, mas neco na githubu? Udelam ti codereview  8)
https://github.com/mprymek/symconfig
Ten odkazovaný tech report je zajímavý, i když celkově to na mě působí jako mnoho povyku pro nic, protože takhle se to normálně dělá, jenom to akademicka přikrášlili a nafoukli.

2232
Vývoj / Re:Nový objev ve funkcionálním programování
« kdy: 23. 04. 2018, 21:31:42 »
Pole je typu typu ω→*→*, i když v tomto případě to je spíš jen nepodstatná náhoda.
Tomu pořád nerozumím :)
Je to typový konstruktor beroucí přirozené číslo, to není pro generika typické. Je to dependent type.

2233
Vývoj / Re:Nový objev ve funkcionálním programování
« kdy: 23. 04. 2018, 20:19:55 »
Ale zase má závislostní typy (typové konstruktory nad hodnotami)
Co tím máš namysli? Teď si tohle vůbec nemůžu vybavit.
Pole je typu typu ω→*→*, i když v tomto případě to je spíš jen nepodstatná náhoda.

2234
Vývoj / Re:Nový objev ve funkcionálním programování
« kdy: 23. 04. 2018, 17:30:09 »
* nevím ovšem na jakou. Asi za mír [v duši všech, kdo píšou něco konkurentního] :)
Nějakou cenu za civil engineering.

2235
Vývoj / Re:Nový objev ve funkcionálním programování
« kdy: 23. 04. 2018, 17:13:44 »
Zajímavé. Některé typy tam generické jsou a nevybavuju si, že by mi někde jinde chyběly, a to jsem v tom napsal hodně kódu.
Jestli myslíš ty zabudované, tak ty jsou iiirc jenom dva - array a map.
chan taky. Právě channels (a příslušný runtime) jsou dle mého skromného názoru na Go to nejlepší, jinak ten jazyk ničím nevyniká.

Stran: 1 ... 147 148 [149] 150 151 ... 153