Díky za článek, zajímavé okénko, i když ta terminologie mne mate. Například na začátku jsou zmíněny operátory and a or - ale v textu jsem nic co by bylo jako "typový and" nenašel - aspoň ne ve smyslu průniku, jak mi to přijde přirozené a je třeba v Lispu - např
(and (integer 0 3) (satisfies evenp))
je 0 nebo 2. Tím operátorem and se tedy myslí některý ze součinových typů (record, tuple)? Na druhou stranu používat and pro v podstatě kartézský součin mi nepřijde čisté.
A proč vlastně to sjednocení musí být disjunktní? Aby v tom match case nezáleželo na pořadí klauzulí?
"typový and" je implicitní u záznamů (tedy v Pythonu u n-tic, pojmenovaných n-tic a datových tříd). Vlastně se tam nepřímo říká něco ve stylu: typ User je složen položky typu Name A SOUČASNĚ z typu Surname atd. Lepší je používat ten původní termín product type, ten to vystihuje lépe, protože popisuje "mohutnost" výsledného typu (viz ten příklad se záznamem s několika položkami typu boolean).
Termín "and" vychází z Curryho–Howardova isomorfismu z teorie typů. To jsem mohl uvést, ale zase jsem ten článek nechtěl udělat "akademickým". Pořád si myslím, že teorie typových systémů je důležitá (ale nedokončená :-), na druhou stranu to může lidi strašit, i když v praxi je to třeba v Pythonu vlastně strašně jednoduché.
ano, ty typy v Elmu jsou taky algebraické
Ovšem Elm a Python jsou z pohledu zápisu zdrojáků na opačné straně spektra:
- u Pythonu se zadávají type hinty u parametrů a návratových hodnot
- Elm má typovou inferenci a odvozuje typy od konkrétních hodnot
Osobně mi vyhovuje spíš ten přístup ML jazyků, ale co už, musíme pracovat s nedokonalými nástroji :-)
čekal jsem, že se rozšíří aspoň F#, ale nějak to pořád ne a ne dojít do mainstreamu
Upřímně vcelku pochybuji, že F# někdy dojde do mainstreamu. Posledních pár let mám pocit, že spíš kráčí opačným směrem.
Hodně novinek ve světě .NETu z poslední doby je totiž pouze pro C#, protože závisí na generátorech zdrojového kódu nebo protože nikdo nepřemýšlel, jak se to bude používat v F#. Navíc původní tvůrce jazyka, Don Syme, už na F# nepracuje. A stávající tým pro F# dělá v pracovní době často věci jiné než F# (aspoň to jsem vydedukoval z některých příspěvků na Twitteru).
Dělal jsem a nedodělal jeden projekt v Haskellu. Obecně vzato dal mi hodně, ale už ho nepoužívám. Maximálně ke studijním účelům "jak by se toto udělalo normálně v Haskellu?"
Pokud považuješ za ML Rust, tak ten ano. Pokud ne, tak ne :-)
F# jsem jen prolétl, ale komunita díky C# je dost nevděčná, takže tam se nic nerozjelo. A Microsoftímu světu se spíše vyhejbám
Kam směřuješ tou otázkou?
Navážu na to, co už psal @radekm.
Moje zkušenost je taková, že klienty jazyk až tak moc nezajímá. Klient má buď firmu, a vytvoří tým vývojářů. Nebo si najme vývojářský tým. Takže to všechno stojí a padá na tom vývojářským týmu. Pokud bude banda vývojářů v Haskellu, kteří nejsou idealisti ale jsou schopni splnit zadání klienta, tak...
S tím souvisí můj dojem, že prostě vývojáři jsou tak trochu hloupí (omlouvám se za aroganci). A spousta těch chytřejších vývojářů položí řemeslo na hřebík a jdou dělat business. Ve výsledku místo toho, aby použili chytřejší jazyky, tak si naberou pod sebe hloupější vývojáře a ti chytřejší jazyky nedávají. Proto stále existuje poptávka po C#, PHP, Javě, C++.
Haskell jsem opustil protože Rust. Rust je výkonější, čitelnější, přátelštější, cargo je lepší jak cabal, v Rustu se dá tak trochu prasit, což někdy potřebuješ. Haskell je čistější, logičtější a správnější. Ale Rust si z něho vyzobal to nejlepší a je strašně, strašně moc dostatečně dobrý.
Hmm, jsem už hodně off-topic? :-)
Ne, to je mojí neschopností, nějaká snad fyzikální knihovna, nebo možná něco s canbus komunikací nebo xml mi myslím vyhazovala výstupy v nějakým (pro mě relativně komplikovaným) tuple, když jsem to vydoloval, vykopíroval do nový proměnný a chtěl s tim pracovat tak to prostě nešlo, nejspíš to byly ty řetězce...
Od tý doby to prostě nemám rád, strávil jsem s tím několik hodin a protože jsem tu knihovnu neznal, neznal jsem ani ty výstupy, v dokumentaci jsem se nic nedočet, takže sem to ladil pokus-omyl....
Tak to jde odzkouset primo v interpretru, co ta Tuple obsahuje:
Tuple = (2, 4, (8, 7, 30), 6, 220, 10, 77, 54)
for item in Tuple:
print(item, type(item))
Vypise:
2 <class 'int'>
4 <class 'int'>
(8, 7, 30) <class 'tuple'>
6 <class 'int'>
220 <class 'int'>
10 <class 'int'>
77 <class 'int'>
54 <class 'int'>
Takze sahnes po Tuple[2] coz je dalsi n-tice. A v ni je prvek 30, kterej te zajima, taky na pozici 2, takze:
Tuple[2][2]
Vyhodi:
30
v Pythonu vede k chybám (hlavně u lidí, co na tento jazyk přecházejí), jak se zapisuje n-tice s jedním prvkem. Úvahy jsou asi následující:
- n-tice se třemi prvky se zapisuje jako (1, 2, 3)
- n-tice se dvěma prvky (dvojice) se zapisuje jako (1, 2)
- a tedy n-tice s jedním prvkem se zapisuje jako (1)
jenže to není pravda, to poslední je jen výraz s konstantou v závorce, správně je (1, )
(Vlastně mi vypadl unit type, ale to je ještě zamotanější :-)
Ono to nevadí do chvíle, než se n-tice používají jako immutable seznamy
jj já vím, jen jsem psal, jak to vidí vývojáři, kteří na Python přechází. Jdou na https://www.w3schools.com/python/python_tuples.asp (například) a tam čtou "Tuples are written with round brackets". Nebo - což asi udělají dnes častěji - se zeptají LLMka (se správně nastaveným system promptem etc.):
"how to write tuple?"
"In Python, a tuple is created by placing comma-separated values inside parentheses (). Here is an example of how to write a tuple: my_tuple = (1, 2, 3, 4, 5) Tuples are immutable, which means their elements cannot be changed after creation."
provider:OpenAI
model: gpt-4
[ale to se dostáváme trošku jinam - k tomu, že každá blbost z LLM už bude nadlouho chápána jako ta jediná pravda, protože je samopotvrzující se]
10. 5. 2025, 12:02 editováno autorem komentáře
To ano, v dnešní době je velmi snadné podlehnout dezinformacím a je proto potřeba pečlivě vybírat kvalitní zdroje, proto také sleduji Vaši práci ;)
Osobně jsem se to naučil od Freda Baptiste, ale třeba tutorial na python.org to má také korektně:
```
A tuple consists of a number of values separated by commas, for instance:
t = 12345, 54321, 'hello!'
```
V "oficiálním" popisu data modelu tamtéž je zmíněn i ten "problematický" singleton.
Pro zajímavost mě gpt-4 s kustomizací https://chatgpt.com/g/g-cKXjWStaE-python odpověl vcelku korektně:
` Create a Tuple`
```
1. With parentheses:
my_tuple = (1, 2, 3)
2. Without parentheses (comma makes the tuple):
another_tuple = 1, 2, 3
3. Singleton tuple (important syntax quirk):
not_a_tuple = (1) # This is just an integer
singleton = (1,) # This is a tuple with one element
4. Using the tuple() constructor:
tuple_from_list = tuple([1, 2, 3])
```
díky kc
10. 5. 2025, 20:35 editováno autorem komentáře
Pořád to je nekonzistentní, pokud by udělali povinnou trailing comma, bylo by to konzistentní pro všechny délky tuple. Ale ne, je to pořád jenom pro jednočlennou n-tici. A trailing comma je povolená a některé formátovače (Ruff) podle ní mohou měnit formátování - prostě zmatek.
Nakonec dojdeme k tomu, že řešením jsou stejně typové anotace - stejně jako v jiných jazycích. Duck typing je přinejmenším kontroverzní věc.