Optimalizace koncové rekurze má svůj smysl, nejde jen o optimalizaci času, ale i o optimalizaci paměti. A tady se snadno můžeme dostat na o stupeň jinou asymptotickou složitost. Což už může být významné, a může to ovlivnit, jak si můžeme dovolit napsat kód. A v tomto mi přijde, že koncová rekurze je často to hlavní, a obecnější optimalizace koncového volání už nepřinese až o tolik navíc.
V tomto případě jsem rychle přečetl popis a přijde mi, že spíše než o optimalizaci koncového volání jde o interpret, který nějak využívá koncového volání.
> člověk ztrácí stack trace, takže ladění je těžší
Jo, to je jedna ze stinných stránek, a tuším i důvod, proč to nedělá automaticky třeba JVM. (Tuším, že byla nějaká iniciativa, která by umožnila označit invoke* instrukce, které lze takto optimalizovat, ale nevím o tom, že by to bylo dokončeno.) A I důvod, proč omezení na rekurzi může být dobrý trade-off.
> obvykle tail call trvá déle než normální call, protože se tam nějak manipuluje se zásobníkem
To by mě zajímalo. Měl jsem za to, že v podstatě místo přidání stack frame se poslední stačí frame přepíše. Jo, bude to vyžadovat nějakou opatrnost – naivně bych prvně nový stack frame vytvořil někde bokem, a pak teprve přepsal starý, protože při tvorbě nového stack frame potřebuju starý. (Představme si situaci, kdy funkce f(a, b) bude volat f(b, a).) Při kompilaci bych čekal, že si s tím poradí optimalizátor, při interpretaci je to trošku otázka, ale nečekal bych, že to bude mít zásadní roli.
On sa namiesto call pouzije jmp, takze existujuci stack frame sa zrecykluje (uz sa tam vraciat nebude, vsak to bolo posledne volanie v tele funkcie, aj v pripade a->b a b->a, pokial nemaju funkcie tolko argumentov, ze musia ist na stack) a az niekedy nastane ret, tak sa vrati tam, odkial sa povodne funkcia volala.
Aby sme pri pohlade na nejake cislo vedeli co sa tam vlastne deje bez toho aby sme museli studovat nejaku 'vtipnu' prirucku k verzovaniu. Ustalili sme sa nejakej forme semantickeho verzovania pre 90% projektov: https://semver.org
Nepotrebujeme dalsiu vedecku disciplinu na hlupost akou je vyjadrenie verzie.
Abys poznal co se tam vlastně děje, tak v každém případě musíš porovnávat dvě verze. Dvě různé hodnoty. Pak je v principu jedno, jestli porovnáváš třeba verzi 134 a 135, nebo 6.12.10 a 6.12.13, nebo 24.04 a 24.10, nebo 3.14159 a 3.141592.
Ve výsledku musíš stejně číst ten verzovací manuál pro každý projekt zvlášť, protože třeba 24.10 verze u Ubuntu znamená něco jiného než u LibreOffice. A 133.1 znamená něco jiného u Firefoxu než 6.12 u jádra (když odhlédneš od velikosti čísel). Aneb, co ti řekne číslo verze 2.11.5 aplikace MyCoolApp jen tak, bez ničeho dalšího?
Navíc, zrovna ten TeX je svým ne-běžným způsobem verzování známý, skoro bych řekl, že je to legenda, která je starší, než mnoho z nás zde.
Mimochodem, zrovna linuxové jádro je krásný příklad. Na první pohled to vypadá jako klasický model <major>.<minor>.<fix>, ale v reálu je to <inkrementující se číslo>.<fix>. Z hlediska vývoje jádra odpovídá jádro 6.12.X něčemu jako 3.72.X. Major se mění jen proto, aby minor nebylo moc veliké. Tříčíselné verzování zůstává jen kvůli kompatibilitě.
11. 2. 2025, 11:17 editováno autorem komentáře
No, kolem toho pred par lety byla zabavna debata, kdys se <fix> priblizilo k 255...
To sice vypadá jako zásadní argument, ale není. Pokud někdo verzuje tak, že přidává další a další číslice nějakého iracionálního čísla, de facto jenom vyjadřuje jejich počet. Tzn. namísto v3.14159 bych mohl napsat v6 a bylo by vymalováno. Pořád to je lidsky použitelnější a dává to okamžitou představu a srovnání. Sémantické verzování je IMO nejlepší, ale každé schema, které je vedeno snahou pomoci čtenáři, je lepší než nějaká geekovská hříčka.
Pořád to je lidsky použitelnější a dává to okamžitou představu a srovnání.
Jaké srovnání? S čím? Jakou představu mi to dává? O čem? Opět platí, že bez znalosti kontextu je to jen a pouze číslo. Stejně jako použitá délka Pi.
S tím lidsky použitelnější bych i souhlasil, ale to je tak vše, protože jediné kritérium je snadná rozpoznatelnost přírůstků při srovnání dvou čísel verzí. U délky Pi je ta rozpoznatelnost už horší. Zjisti si ale aktuální verzi TeX-u a zjistíš, že jich zase tak moc nebylo. Za celou historii. Ten SW je psaný prostě jinak, než je dnes zvykem.
Zrovna TeX je software, který je od verze 3 koncipován tak, že je „tesán do kamene“ a neměnný, s výjimkou (vzácných) bugfixů. Navíc, Knuth oznámil svůj záměr zakončit vývoj TeXu tím, že bude zakonzerovaný tak, jak je, tzn. že z bugů už vlastně budou featury.
Jakmile máte verzi 3.něco, tak máte jistotu, že se to bude chovat v zásadě stejně.
nojo a koukam ze je kolem toho je i nejaka podpora https://github.com/python/cpython/pull/125035