Názory k článku Rekurzivní datové typy v jazyku OCaml

V F# to asi bude hodně podobné, ale ten má uniony s hodnotou, takže minimálně ten basic_color se obejde bez funkce :-)

tak tak, v F# je to maličko jednodušší.

> Odvození (inferenci) datových typů za nás provede OCaml automaticky (a stále se bude jednat o silné typování)

Trochu si zarejpu.
Kde je ta hranice, kdy se jedná o silné a kdy už o slabé typování? Mě na základě studia všech těch definic přišlo, že tato kategorizace je úplně blbá. Ve všech těch případech buď jde o ne/povinnou asserci, nebo o automatické přetypování (javascript). Více jsem tam toho nenašel.
V případě inference je jedno, že si to stroj odvodí sám, ale ten typ tam je a provede se podle něj kontrola.
Jenže třeba Python je oficiálně považován za strong typing. S čímž bych nesouhlasil.

Povězte mi, co mi uniká?

To je dobrá otázka :-)

Hele já to chápu takto. Máme jazyky, Java atd., kde:

int x;

mě jasně říká, jakýho typu to x je.

Potom máme jazyky, kde se píše jen:

x=42

No a tady (IMHO) ty silně typované odvodí, že "x" je typu int a už tam nepovolí zapsat jinou hodnotu (třeba ten OCaml - tedy kdyby to bylo mutable :-).

A potom ty slabě typované bez mrknutí oka povolí například:

x=42
x=None
x="foo"
x=[1,2,3]

def x():
   pass

(no a ještě se to dělí na jazyky, které zkousnou například "foo" + 1 nebo https://github.com/denysdovhan/wtfjs#banana a "nějak" to zařídí a jiné, které za toto už programátorovi vynadají)

Jinak Pythonu s type hinty, tomu typovému systému říkají "sound". to je takové zvláštní, ale zase proč ne.

Asi je do dobře vidět na obrázku https://storage.googleapis.com/www.josephspurrier.com/wp-content/uploads/2014/02/strongweakstaticdynamic_type.png (těch existuje hafo, tak jsem vybral nějaký s F#, když už tam není OCaml)

K tomu třetímu příkladu uvedu, že třeba Rust to umožňuje, protože po změně typu té proměnné to je vlastně jiná proměnná. Jakmile by došlo k nějakému konfliktu (teď si nedovedu představit jak), tak to neumožní. Faktem je, že co programátorského stylu, tak to není úplně přátelské pro kolegy. Jenže třeba Erlang má proměnné imutable, a taky to moc příjemné není.

V pythone su premenne tiez imutable (az na niekolko malo vynimiek). Typovo silny je pre to, ze neumoznuje implicitne pretypovanie.

Python 3.11.6 (main, Oct  3 2023, 00:00:00) [GCC 13.2.1 20230728 (Red Hat 13.2.1-1)]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.9.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: # ad imutable

In [2]: a = b = 1

In [3]: id(a)
Out[3]: 139887626845928

In [4]: id(b)
Out[4]: 139887626845928

In [5]: a=2

In [6]: id(a)
Out[6]: 139887626845960

In [7]: id(b)
Out[7]: 139887626845928

In [8]: # ad silne typovanie

In [9]: 1+1 # ok, oba typy rovnake
Out[9]: 2

In [10]: 1+"1" # chyba, rozdielne typy
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[10], line 1
----> 1 1+"1" # chyba, rozdielne typy

TypeError: unsupported operand type(s) for +: 'int' and 'str'

Z toho, co jsi napsal, naopak vyplývá, že proměnné immutable nejsou. Pokud by byly, tak by řádek a=2 selhal, protože v a už je přiřazená hodnota 1.

Proměnné v Pythonu jsou mutable pointery na objekty, z nichž některé jsou immutable (jako třeba int) a některé mutable (jako třeba list)

Žádný konflikt nehrozí; jak píšeš, jde o jinou proměnnou, která se jenom holt jmenuje stejně jako původní. Dá se to představit třeba tak, že se vytvoří nový interní blok, kde to jméno přebírá další proměnná. A rozdíl je ještě v tom, že jiný typ nevznikne prostým přiřazením, ale pomocí "let".

to je ono, podstatný rozdíl. Python se snaží obejít bez "let", což je na jednu stranu jakoby snažší (a víc nebezpečné), na stranu druhou potom musí zavádět global a local, takže si asi člověk nevybere :-)

Ide o to do akej miery povoluje interpreter alebo prekladac implicitne pretypovanie. Napr. PHP bez problemov scita 1+"1" (integer a string) tym ze si implicitne ten string pretypuje na integer. Dalej izolacia odvodenych typov. Napr. v ADA nescitate typ jabka a typ hrusky hoci oba boli odvodene od integer. Musite ich explicitne pretypovat alebo definovat operator ktory ich scitat dokaze.

Jo, je blbá.

Jo no, to je takový amorfní termín. Je to docela zvláštní, protože za typovými systémy je dost rozsáhlá teorie, takže i terminologie by měla být jednotná. Tady konkrétně mě šlo o to, že se odvodí typ funkce a potom při dalších pokusech o jejich volání se to silně testuje. Python toto (bez type hintů) vůbec nemá.

Na druhou stranu - OOP je ještě horší, tam se neshodneme ani na tom, o čem to je :-)

Tak wikipedia k tématu vysloveně píše:
"However, there is no precise technical definition of what the terms mean and different authors disagree about the implied meaning of the terms and the relative rankings of the "strength" of the type systems of mainstream programming languages.[1] For this reason, writers who wish to write unambiguously about type systems often eschew the terms "strong typing" and "weak typing" in favor of specific expressions such as "type safety"."