Jak se píše programovací jazyk 4: Objektový layout (diskuse)

[Pavel Křivánek]

Takže pro vyhledávání slotů používáš DFS. Uvažoval jsi o plném prohledávání tak, jak to dělá Self?

Jsem zvědav, jak budeš řešit kontexty a procesy

[Bystroushaak]

Uvažoval jsi o plném prohledávání tak, jak to dělá Self?

Mám na to issue, ale ještě jsem se k tomu nedostal. Četl jsem někde v paperu od Davida Ungara, že bez toho to není úplně korektní.

Jsem zvědav, jak budeš řešit kontexty a procesy

Procesy už mám +- vyřešené. Co je konkrétně myšleno kontexty? Lokální scope?

[Pavel Křivánek]

Četl jsem někde v paperu od Davida Ungara, že bez toho to není úplně korektní.

U složitějších systémů se bez toho dá hůře odhadnout, jak se bude program vlastně skutečně chovat, ale na druhou stranu přináší DFS větší flexibilitu.

Co je konkrétně myšleno kontexty? Lokální scope?

Myslel jsem obecně přístup ke stacku a případnou manipulaci s ním

[Bystroushaak]

Myslel jsem obecně přístup ke stacku a případnou manipulaci s ním

To bude vidět v příštím díle. Já si to dělám dost po svém a taky je to z jisté míry ovlivněné pythonem, ve kterém to píšu, tak se to bude asi lišit poměrně hodně od toho co je v Selfu.

Momentálně řeším nejvíc pomalost, kde už jsem zoptimalizoval kde co, a dostal jsem se někam k 3 vteřinám na 1 milion while cyklů, což je pořád hrozně pomalé. Teď se snažím ve vedlejší branchi implementovat cacheování slotů a dynamickou rekompilaci bytecode, kde podle profileru parent lookupy zabírají víc jak 70% výkonu.

[kralyk z abclinuxu]

Uvažoval jsi o plném prohledávání tak, jak to dělá Self?

Ze zvědavosti: Jak to dělá Self? Nedělá DFS?

[Pavel Křivánek]

Když Self prohledává sloty v rodičích, prohledá úplně všechny možnosti a pokud hledanému slotu odpovídá více možností, vyhodí chybu. Jediná validní možnost, jak překrýt definici nějakého rodičovského slotu, je udělat to v rámci vlastních slotů objektu, nemůžete k tomu použít jiného rodiče.

[Bystroushaak]

Když Self prohledává sloty v rodičích, prohledá úplně všechny možnosti a pokud hledanému slotu odpovídá více možností, vyhodí chybu. Jediná validní možnost, jak překrýt definici nějakého rodičovského slotu, je udělat to v rámci vlastních slotů objektu, nemůžete k tomu použít jiného rodiče.

Jen dodám, že pak je nutné použít resend (směrování do konkrétního parenta), což je korektní řešení.

[kralyk z abclinuxu]

Když Self prohledává sloty v rodičích, prohledá úplně všechny možnosti a pokud hledanému slotu odpovídá více možností, vyhodí chybu. Jediná validní možnost, jak překrýt definici nějakého rodičovského slotu, je udělat to v rámci vlastních slotů objektu, nemůžete k tomu použít jiného rodiče.

Aha, rozumim. To připomíná řešení ambiguit v multiple inheritance kde např. jazyky jako C++ taky vyhazují chyby v podobných situacích, zatímco například v Go tohle přehlédli a jsou z toho pak problémy.

[Bystroushaak]

Uvažoval jsi o plném prohledávání tak, jak to dělá Self?

Nedávno jsem to implementoval btw.

[kralyk z abclinuxu]

Jednou z naprosto klíčových funkcionalit Selfu, která mu dodává mnoho elegance, jenž například postrádá javascript, je delegace na rodičovské sloty.

Chápu to správně, že ten rozdíl oproti JavaScriptu je v tom, že v JS může mít objekt pouze jednoho rodiče?

Object obsahuje kromě metody .get_slot(), jenž pouze hledá v mapě patřičný slot také metody .parent_lookup() a .slot_lookup().

Chvíli mi dalo tuhle větu rozparsovat, jestli jsem to pochopil správně, chtělo by to čárku mezi 'slot' a 'také'.

[Bystroushaak]

Chápu to správně, že ten rozdíl oproti JavaScriptu je v tom, že v JS může mít objekt pouze jednoho rodiče?

Spíš že do javascriptu je to tak divně naprasené, že se to reálně stejně moc nepoužívá, kdežto v Selfu je to doslova základ a staví na tom prakticky každý objekt, včetně třeba právě implementace lokálního scope. Podle mě to není jen kulturou, ale i podporou v syntaxi.

Ono obecně, prototypy v javascriptu tě tlačí k tomu přát si aby to byl class based systém. Prototypy v Selfu oproti tomu působí přirozeně a konzistentně.

Chvíli mi dalo tuhle větu rozparsovat, jestli jsem to pochopil správně, chtělo by to čárku mezi 'slot' a 'také'.

Máš pravdu, opravím to.

[kralyk z abclinuxu]

Spíš že do javascriptu je to tak divně naprasené, že se to reálně stejně moc nepoužívá, kdežto v Selfu je to doslova základ a staví na tom prakticky každý objekt, včetně třeba právě implementace lokálního scope. Podle mě to není jen kulturou, ale i podporou v syntaxi.

Ono obecně, prototypy v javascriptu tě tlačí k tomu přát si aby to byl class based systém. Prototypy v Selfu oproti tomu působí přirozeně a konzistentně.

Afaik v JS je to dané mimo jiné také optimalizacemi, viz tady a tady.

[Ruža Becelin]

"pseudoUML" je PlantUML - absolutne genialni vec

[Bystroushaak]

Já jsem tím pseudoUML myslel spíš ty diagramy, že to moc nedodržuje UML standard. Generované to je v PlantUML, bude o tom ještě jeden díl tohohle seriálu, kde bude ukázka jak jsem to použil k debugování a optimalizacím.

Zrovna včera když jsem předělával ty materiály k článku jsem navíc dostudoval dokumentaci a docela jsem čuměl, co všechno to už umí. Například že tam jsou makra jsem netušil. Možná o tom zkusím časem sepsat nějaké představení.

[Ruža Becelin]

Jo, je to super vec, delal jsem pilot na automatizaci infrastruktury a jako nahradu Visio a dalsich.

S kazdou dalsi verzi je to lepsi a lepsi, zatim je muj dojem, ze na sekvencni a class diagramy je to prakticky nejlepsi, ale staticke diagramy (popis site atd) to jeste uplne nezvlada - zrejme to narazi na limity gnuplot.

[Bystroushaak]

Já se to snažil včera ohackovat aby mi to nakreslilo v podstatě vennův diagram, tedy čtvereček kolem objektu a mapy a pak čtvereček kolem druhého objektu, s tím že ta mapa bude v obou čtverečcích. Čtvereček nakreslit šel, ale ten zbytek ne.

Jinak mě hodně překvapila podpora [hidden] u šipek, kde můžeš konečně silou donutit layout vykreslit se jak chceš. To mi dřív vždycky trvalo hrozně dlouho.

Začal jsem na to teď psát takový python wrapper, kde jen skládáš třídy do sebe a pak ti z toho krásně vypadne UML graf, ale zatím je to jen takové experimentování. Je to ale super právě na vizualizace třeba těch scope chainů.

[xkucf03]

BTW: když je řeč o diagramech, znáte někdo Adaptagramy a Dunnart? Přijde mi to jako (takřka) ideální kompromis mezi ručním kreslením grafu a automatickým generováním z nějakého předpisu – základem je vlastně předpis podle kterého lze vygenerovat graf, ale člověk k tomu může přidat různá omezení, jako tenhle uzel má být přesně tady nebo mezi těmito uzly mají být stejné mezery nebo tyhle uzly mají být na vodorovné přímce.

[Ruža Becelin]

Jinak pouzivam parametr uml2, ktery by mel vykreslovat trochu "presnejsi" UML.

[xkucf03]

Funguje tam přetěžování ¹ metod? Když je to implementované jako slovník, tak asi ne. Nebo je klíčem něco jiného než název metody?

Jak se to bude chovat v případě, že zavolám metodu na neexistujícím objektu (None)? Vyletí něco jako NullPointerException nebo to budeš řešit nějakým lepším způsobem? Když jsem nad tím někdy přemýšlel – tedy v kontextu třídní dědičnosti – tak jsem si říkal, že by třída mohla definovat výchozí chování metod pro případ, že je zavoláš na null objektu. Pak by šlo implementovat chování třeba tak, že když se pokusíš iterovat přes chybějící (null) seznam, chovalo by se to stejně, jako kdybys iteroval přes prázdný seznam. U té prototypové dědičnosti víš, jakého typu mělo být None, nebo ne?

_{[1] více metod se stejným názvem a různými parametry (ne překrývání)}

[Bystroushaak]

Funguje tam přetěžování 1 metod? Když je to implementované jako slovník, tak asi ne. Nebo je klíčem něco jiného než název metody?

Ono je to hlavně dynamicky typované, takže víc metod se stejnými názvy nedává smysl, nemáš je podle čeho rozlišit. Metody tam navíc nejsou, jsou to zprávy a počítá se pouze název zprávy.

Jak se to bude chovat v případě, že zavolám metodu na neexistujícím objektu (None)?

Přemýšlím jak by k tomu mohlo dojít a nic mě nenapadá. Nic jako neexistující objekt tam není. Interně se None sice používá, ale to je na úrovni implementace, ne na úrovni něčeho k čemu bys mohl přistupovat z tinySelfu samotného. Je tam nil, ale to je prostě jen singleton normálního objektu, takže se na to reaguje jako když pošleš zprávu libovolnému jinému objektu (momentálně to mám nastavené tak že to spadne a vypíše debug, ale správně by to mělo fungovat tak že se dá objektu šance reagovat (vyhledání metody pro dynamický resolve) a pokud se nenajde, zavolá error handler).

Pak by šlo implementovat chování třeba tak, že když se pokusíš iterovat přes chybějící (null) seznam, chovalo by se to stejně, jako kdybys iteroval přes prázdný seznam.

Tam nikdy nic jako null seznam nebude.

[xkucf03]

momentálně to mám nastavené tak že to spadne a vypíše debug

Což je vlastně ten NullPointerException.

ale správně by to mělo fungovat tak že se dá objektu šance reagovat (vyhledání metody pro dynamický resolve) a pokud se nenajde, zavolá error handler).

To už odpovídá tomu mému nápadu. Akorát u té třídní dědičnosti je výhoda v tom, že víš, jakého typu ten null měl být, takže víš, ve které třídě hledat. V dynamickém systému tahle informace chybí, takže to asi spadne do nějakého obecného objektu, předka všech předků, a v něm se to nějak genericky zpracuje. Šlo by z toho vytáhnout aspoň ten kontext/objekt, ve kterém se ten chybějící slot nacházel?

Tam nikdy nic jako null seznam nebude.

Jak se to tedy bude chovat v případě, že na nějakém místě očekávám seznam, ale on tam není a místo toho to ukazuje na nil objekt? To je přece v principu stejné, jako kdybych měl proměnnou, ve které čekám ArrayList, ale bylo v ní null, ne?

[Bystroushaak]

To už odpovídá tomu mému nápadu. Akorát u té třídní dědičnosti je výhoda v tom, že víš, jakého typu ten null měl být, takže víš, ve které třídě hledat. V dynamickém systému tahle informace chybí, takže to asi spadne do nějakého obecného objektu, předka všech předků, a v něm se to nějak genericky zpracuje. Šlo by z toho vytáhnout aspoň ten kontext/objekt, ve kterém se ten chybějící slot nacházel?

Momentálně je to jen ve fázi návrhu, takže jak si to udělám, takové to bude. Teď řeším hlavně rychlostní optimalizace, s tím že cílem je se dostat s milionem while cyklů pod jednu vteřinu (while cyklus v každé iteraci testuje a vytváří dynamickou lambda funkci), a ideálně pod 100ms. Jsem někde okolo tří vteřin bez jitu.

Jak se to tedy bude chovat v případě, že na nějakém místě očekávám seznam, ale on tam není a místo toho to ukazuje na nil objekt? To je přece v principu stejné, jako kdybych měl proměnnou, ve které čekám ArrayList, ale bylo v ní null, ne?

Tak jako vždycky v ducktypovaných jazycích (třeba pythonu), padne to na tom že se objektu pošle zpráva které nerozumí. Momentálně by se to prostě ukončilo, ale to je čistě jen řešení ve stylu „v téhle fázi vývoje mě to nezajímá“. V budoucnosti v tu chvíli dojde k zavolání error handleru na dané úrovni stackframe, což pokud není změněno kódem, tak povede ke spuštění interaktivního debuggeru. Ten error handler už tam mám teď, akorát se prostě nevolá u chybějícího slotu, protože se mi teď nechtělo.

Trochu koketuji s myšlenkou, že bych dovolil metodám definovat rozhraní parametrů a výstupní hodnoty, a přidal k tomu nějaké statické typování, ale není to v TODO, jen ve fázi „hm, to by nemuselo být špatné“.

Funkcionalita momentálně z větší části klonuje Self.

[kralyk z abclinuxu]

Když jsem nad tím někdy přemýšlel – tedy v kontextu třídní dědičnosti – tak jsem si říkal, že by třída mohla definovat výchozí chování metod pro případ, že je zavoláš na null objektu. Pak by šlo implementovat chování třeba tak, že když se pokusíš iterovat přes chybějící (null) seznam, chovalo by se to stejně, jako kdybys iteroval přes prázdný seznam.

Tohle řeší funcionální a jimi ovlivněné jazyky typovým systémem a použitím ADTs.

Tady máš příklad v Rustu. (Ta metoda get_list() náhodně vrací "nic" nebo vektor čísel.)

Přijde mi to lepší mj. v tom, že to není závislé na objektech / dědičnosti a můžeš se rozhodnout, co dělat s prázdnou hodnotou, jak zrovna potřebuješ, není to zadrátováno v té třídě.

[xkucf03]

Z hlediska zápisu a pohodlnosti se to:

let list = get_list().unwrap_or(vec![]);

ale moc neliší od:

list = list == null ? Collections.emptyList() : list;

(mimochodem v Javě někdy používám svoje notNull())

To Option.unwrap_or() tě akorát donutí se k té null hodnotě nějak postavit a nezapomenout na její ošetření. Ale tu práci a rozhodování musíš udělat tak jako tak. (a pokud nezapomínáš nebo ten kód testuješ, tak v tom opravdu moc velký rozdíl není)

Mně šlo spíš o to mít možnost, se téhle práce úplně zbavit, resp. přesunout to rozhodování někam jinam, aby nebylo rozeseté všude možně v kódu. Přišlo by mi fajn mít možnost na jednom místě definovat, jak se chovat k chybějícím hodnotám různých typů.

Přijde mi, že někdy by se to hodilo mít definované tohle výchozí chování na úrovni tříd. Na druhou stranu je pravda, že by to šlo řešit i tím, že null prostě nikde nebude a místo něj budeme mít jen nějaké singletony, které tam dáme místo něj a budou jednak symbolizovat, že jde o prázdnou hodnotu (akorát místo if(a == null) se bude psát if (a == Někde.nějaký.SINGLETON) nebo if (isMissingValue(a))).

Např. když budu mít atribut, který definuje nějaké filtrovací pravidlo, tak null by se interpretoval tak, že se nic filtrovat nemá a projde vše. Ale taky by šlo vynutit (např. nějakou anotací nebo klíčovým slovem), že ten atribut null nikdy nebude – a když v něm budu chtít mít prázdný filtr, tak tam dám singleton, který bude na všechno odpovídat true, tudíž projde vše.

[JS1]

Přišlo by mi fajn mít možnost na jednom místě definovat, jak se chovat k chybějícím hodnotám různých typů.

To se dela pres monady. Option je monada, takze muzes skladat funkce co s ni vselijak pracuji aniz bys musel resit, jak presne se chova.

[kralyk z abclinuxu]

Přijde mi, že někdy by se to hodilo mít definované tohle výchozí chování na úrovni tříd.

Tak v tom Rustu se tohle nestane, protože tam žádný null není a každý objekt je vždy platný. Ten Option je jen obyčejný enum a None je jen varianta tohoto enumu, nemá žádný specielní význam pro kompilátor. Takže v zásadě ti nic nebrání si nadefinovat vlastní typ, který bude nějakým jiným způsobem reprezentovat prázdnou hodnotu, třeba pomocí Default, jako např. takhle, to by asi zhruba byl rustový ekvivalent toho, co chceš, ačkoli obecně se to nepoužívá, protože to není potřeba, viz dále...

Ale taky by šlo vynutit (např. nějakou anotací nebo klíčovým slovem), že ten atribut null nikdy nebude

Ano, pokud vyloženě nemáš null-free jazyk, tak můžeš třeba udělat to, co dělá Kotlin.

Náhradou "null" je pak konkrétní stav nějakého objektu, například u toho vektoru prostě vrátíš prázdný vektor a s null se nezabýváš, protože to nemá v té chvíli smysl - proč přidávat další možný stav objektu (null) jen proto, abys ho následně natvrdo namapoval na již existující stav (prázdný vektor)?

[xkucf03]

třeba pomocí Default, jako např. takhle, to by asi zhruba byl rustový ekvivalent toho, co chceš

Dík, vypadá to zajímavě.

[Bystroushaak]

Náhradou "null" je pak konkrétní stav nějakého objektu, například u toho vektoru prostě vrátíš prázdný vektor a s null se nezabýváš, protože to nemá v té chvíli smysl - proč přidávat další možný stav objektu (null) jen proto, abys ho následně natvrdo namapoval na již existující stav (prázdný vektor)?

Jo, přesně.

[Bherzet]

Však Java má Optional, což je potom 1:1 jako ta ukázka z Rustu.

Ke zbytku tématu: Nějaká implicitní konverze z null na sémanticky ekvivalentní instanci cílového typu by mohla být fajn. Mně osobně se hodně líbí nullable typy v C# (zjednodušeně: proměnná typu Foo? může být nastavena na null, proměnná typu Foo nikoliv). C# obecně je Java na steroidech, alespoň co se core jazyka týká.

[kralyk z abclinuxu]

Však Java má Optional, což je potom 1:1 jako ta ukázka z Rustu.

Když zamhouřím oči tak jo. Když nezamhouřím, tak si budu stěžovat minimálně na to, že ten Optional může sám být null, takže odpovídá spíš něčemu jako Option<Option<T>> ...

Mně osobně se hodně líbí nullable typy v C# (zjednodušeně: proměnná typu Foo? může být nastavena na null, proměnná typu Foo nikoliv). C# obecně je Java na steroidech, alespoň co se core jazyka týká.

Stejně to má i Kotlin, asi to převzali z C#...

[Bherzet]

Když zamhouřím oči tak jo. Když nezamhouřím, tak si budu stěžovat minimálně na to, že ten Optional může sám být null, takže odpovídá spíš něčemu jako Option<Option<T>> ...

Pravda, přehlédl jsem, že ty v tom Rustu vracíš None a ta konverze na Option proběhne implicitně. Nicméně já bych stav, kdy samotný Optional bude null, stejně neošetřoval, přijde mi to hloupé. IMHO nemá smysl psát každou metodu bullet-proof tak, aby nebylo možné ji rozbít. V ideálním případě by jazyk vůbec neumožnil tam ten null poslat, když to neumí, bude to padat za běhu a ne v čase kompilace. To statické typování v Javě holt má svoje problémy.

[kralyk z abclinuxu]

Pravda, přehlédl jsem, že ty v tom Rustu vracíš None a ta konverze na Option proběhne implicitně.

No, ona to není konverze. None je jedna z variant enumu Option, tj. reálně ta funkce vrací Option::None. V Rustu může člověk importovat do scope nejen ten enum (tj. typ), ale i jeho varianty. A ten Option jakož i jeho varianty jsou by-default importovány, prostě protože se to používá často. Proto je možný prostě vrátit None.

Nicméně já bych stav, kdy samotný Optional bude null, stejně neošetřoval, přijde mi to hloupé. IMHO nemá smysl psát každou metodu bullet-proof tak, aby nebylo možné ji rozbít. V ideálním případě by jazyk vůbec neumožnil tam ten null poslat, když to neumí, bude to padat za běhu a ne v čase kompilace.

Jo, s tim souhlasim, je to trochu hnidopišská připomínka. Afaik mají v plánu to fixnout přidáním podpory value types, ale nevim, jak je to daleko...

[Bherzet]

Jestli jsem to správně pochopil, tak value types mají být spíš jakousi obdobou struktur, resp. lightweight objektů.

[Odin1918]

Moc pekne. Premyslel si o kompilovani bytecode i pro JVM? Prijde mi, ze by to vyznamne rozsirilo moznosti vyuziti.

[Bystroushaak]

Přemýšlel hned v začátku, ale pak jsem to zavrhl. Nejsem první kdo zkoušel psát Selfovou implementaci nad JVM a selhal. Navíc nemám úplně rád javu.

Na druhou stranu, jak jsem psal pod tím druhým blogem, začal jsem chodit na přednášky Jaroslava Tulacha na Matfyzu ohledně GraalVM / Truffle, takže se dá čekat že třeba do roka zkusím udělat nějakou implementaci až tohle ustabilizuji.

Momentálně je můj postoj k tinySelfu nejlíp vysvětlený asi tady: https://www.notion.so/tinySelf-57c3b418d3bc4c879fad5c5397310d86

[Pavel Křivánek]

Nestálo by za úvahu ještě doplnit speciální zprávy, které by umožnily method wrappers a vlastní delegaci? Ve Smalltalku můžeš na místě metody použít jakýkoliv objekt, který rozumí zprávě #run:with:in:, kdybys použil něco podobného i pro delegaci, určitě by ti to usnadnilo vytváření object proxies a tvorbu distribuovaných objektových pamětí.

[Bystroushaak]

Je to v plánu. Přemýšlel jsem zatím nad nějakou obdobou pythonního __getattr__().

[OKBet]

This post is really informative and you have posted such precious and informative article. online casino using gcash