Dotaz: Vlastny funkcionalny jazyk - automaticke odvodzovanie typov

[hermes]

Robim si staticko dynamicky programovaci jazyk. Uz to generuje funkcny kod.

ale chcel by som tam teraz doplnit odvodzovanie typov na styl Ocaml teda Hindley-Milner typovy system:

#takto sa typ odvodzuje lahko:

let foo = 5 # odvodi foo : int
let bar = "Abc" # odvodi bar : string

# ale co toto:

# baz by mala mat typ: int -> int
let baz = func a -> a + 2

let qux = func a -> a + a 

# zavolame funkciu s ciselnym parametrom
qux 2

# zavolame funkciu zo stringovym parametrom
qux "Hahaha"

Pri tom poslednom priklade je uz otazka, ci by ta funkcia nemala byt polymorficka, alebo ci sa ma inferovat podla prvej pouzitej hodnoty a pri druhej vyhodit chybu.

Viete mi v skratke vysvetlit, alebo odkazat ma na priklad, clanok, ci rovno hotovu kniznicu ako ten Hindley-Milner typovy system funguje?

Samozrejme je mi jasne ze v urcitych situaciach automaticke odvodzovanie typov fungovat nebude a vtedy compiler vyhodi chybu a editor "vyzve" programatora, aby tam vlozil typovu anotaciu.

Taktiez tam bude kedyword auto, ktorym sa vytvori nova premenna typu dynamic ktora bude moct obsahovat data hociakeho typu. Ale to sem nechcem teraz do toho pliest.

auto x = 12 
# premenna typu dynamic

Odpovědi

[debian+]

Studoval si najprv?: https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Parametric_polymorphism

[debian+]

Vid. zdroje. Napr.: https://github.com/wh5a/Algorithm-W-Step-By-Step/blob/master/AlgorithmW.pdf

[hermes]

Vecer precitam.

Ale nasiel som si velmi nazorny a jednoduchy demonstracny priklad. Teraz som v praci preluskam to vecer dik za odkazy.

[debian+]

Nechces sa podelit.

[hermes]

Jaj jasné. Tu je

[Sten]

Přijde mi to jako generické lambdy v C++. Tam je to implementované pomocí šablon.

[debian+]

Inac, Tvoj jazyk kompilovaci alebo intepretacny?

[hermes]

Kompilovaný kompiluje sa do vyššieho programovacieho jazyka (do akého zatiaľ nenapíšem) a z neho do LLVM -> a natívneho kódu alebo aj JS (cez Emscripten) . Nechcem zatiaľ písať podrobnosti kým to nebude v takej fáze, že budem môcť dať von nejakú funkčnú verizu. A mať hotový aj web s podrobným manuálom a blog s nejakým tutorálom a pluginy do najpoužívanejších editorov (Zatiaľ mám plugin len pre VSCode)

Už to generuje funkčný kód, ale stále to má ďaleko od dokončenia. A kôli typom sa to asi posunie minimálne o mesiac.

[debian+]

To si si mal premysliet na zaciatku, aku chces silno typovy jazyk. Tak to riesis teraz za behu.

[hermes]

Máš pravdu že by bolo lepšie keby som mal hneď od začiatku jasnú predstavu čo od jazyka chcem. A podľa toho napísal zadanie a bod po bode podľa neho napísal aplikáciu.

Ale vlastne som to zo začiatku ani sám nevedel. Mal som pár nápadov a hmlisté predstavy ako ich zrealizovať. Ale presnú predstavu o typovom systéme som zo začiatku nemal, len som vedel že typová kontrola bude primárne statická, no zároveň chcem (hlavne kôli OOP pridať aj typ dynamic. V dnešnej dobe sa hodí oboje...

Lebo keď si pozrieš vačšie projekty tak často sa skladajú z časti napísanej v staticky typovanom jazyku ako C++ a potom to zlepia nejakým dynamickým jazykom ako LUA alebo Python.

[Miloslav Ponkrác]

O typovém systému je opravdu potřeba rozhodnout na začátku.

Statický typový systém vede k jiným řešení. Dynamiku nad typy pak přidávají přetěžováním podprogramů a generickým programováním. Side effect statického typování je efektivita dat - není třeba k hodnotě přidávat typ, ani ho runtimově řešit.

Dynamický typový systém na to jde opačně. Primárně ke každé hodnotě přiletí runtimově i typ. Když chce dynamický typový systém napodobit statické typování - jednoduše přidá constraint na datový typ k proměnné, parametrům funkcí, apod.

Musíte se rozhodnout. Vše má svá pro a proti.

Měl byste vědět, jakou filozofii jazyka požadujete, a k čemu ten váš programovací jazyk má sloužit. Podle toho odvodíte i ostatní.

[hermes]

Zadanie resp todo list si robím pred každou vačšiou časťou toho jazyka a potom doňho pridávam ďaľšie nápady ako to vylepšiť, niečo naopak škrtnem, alebo občas niečo prepíšem a nad všetkým silno premýšlam, aby z toho vznikol jeden konzistentný celok a aby som priniesol aj nejaké nové nápady.

[Kit]

Je dobré mít těch jazykových konstruktů co nejméně, aby ten jazyk nebyl moc složitý. Také co nejvíc funkcionalit vytlačit do knihoven a v jádře ponechat jen nezbytné minimum.

[Miloslav Ponkrác]

Jazyk klidně může být složitý, když to vyžaduje jeho účel. Knihovny nemohou řešit vše, jen tak mimochodem.

Napsat oholený a blbý jazyk nemusí být vždy cílem.

[Kit]

Nevidím rozpor. Snad jen v tom, že jazyk by určitě neměl být složitý, což historie potvrzuje.

[Miloslav Ponkrác]

Ani já nevidím rozpor. Jednoduchost/složitost by neměla být cílem.

Funkcionální jazyky obvykle bývají směšně jednoduché.

[Kit]

Vodopádový model se moc neosvědčil. Agilní přístup je pro takové projekty výhodnější. Na slepé uličky se prostě narazí dříve.

[Miloslav Ponkrác]

Agilní přístup je na houby, pokud potřebujete věci promyslet. Z agilního přístupu nikdy nevznikle ani dobrý programovací jazyk ani dobrá knihovna ani dobrý operační systém.

Agilní přístup plodí jen nalepováky na nalepováky.

[Kit]

A vodopádový přístup se v dnešní době dá použít snad jen v korporacích, ale i tam je zoufale neefektivní.

[Miloslav Ponkrác]

Jedno je nad slunce jasné: Použít jakoukoli agilní metodiku při návrhu nového programovacího jazyka, navíc v jedné osobě - je ptákovina na kvadrát.

Návrh programovacího jazyky potřebuje především dokonale promyšlené základy a vlastnosti jazyka - což je v kontadiktu a opozici k jakékoli agilní metodice.

[Kit]

V žádném případě to není ptákovinou. Napsal jsem už několik jazyků tímto způsobem, které dodnes plní svůj účel.

[Miloslav Ponkrác]

Je to ptákovina, pokud chcete napsat DOBRÝ a PROMYŠLENÝ jazyk.