tomkren / tfgpy Goto Github PK

Interní produkty (aka tuply, aka seznamy z interních pairů) představujou přirozenou prerekvizitu pro LNF-applikace, která je z technickýho hlediska obtížnější část než druhá půlka, LNF-abstrakce, která se děje spíš šikovnym zavedenim v lokálního kontextu jakožto typového konstruktu, tak aby fungovalo kešování beze změny.

Teď se to dělá (kešujou se výsledky dotaszů pro sub-produkty) a myslim, že to je špatně, takže to předělávám na verzi, co to nedělá se záměrem otestovat, jakej to má vliv na performance.

(Zároveň je to přirozená cesta k smysluplně naprogramovanejm a definovanejm stromům v LNF s abstrakcema)

test_generator.py bysme měli zasadně projít a pročistit

dumb uf_tree succesors dává víc následníků než smart:

[dumb]     (((k (? ?)) ?) ?)  --> num=2  ... (((k (s ?)) ?) ?), (((k (k ?)) ?) ?)
[smart]    (((k (? ?)) ?) ?)  --> num=1  ... (((k (k ?)) ?) ?)

Pracuju na separaci bugu v test_generator.py : separate_error_bad_smart_expansion_2017_02_28()
Mám separováno, zjistil jsem, že dumb to bohužel dela dobře, protože je obydlenej následujicimn:

(((k (s k)) s) s)
is_well_typed: True

Plán: Na papir si opsat typ toho protipříkladu a rekonstruovat, kde se to při generování vysere.

Všiml jsem si, že občas se použije u jednoduchý unifikace spíš nová proměna z fresh verze typu symbolu, než z goaslu, jak by bylo přirozenější.

Proto navrhuju prozkoumat mechanizmus MGU, aby to z tohoto pohledu vychazelo co nejlíp, tedy pokud je možná volba mezi x |-> y a y |->x, tak zvolit tu co nezavede do unifikovaného typu nove promené ale co nejvíc používa proměnné z goalu.

počítá se to:

counts[App] + counts[Leaf] - counts[UnfinishedLeaf]

... ale to se mi zda blbě, myslim že má bejt:

counts[App] + counts[Leaf]

Dobře by to bylo, pokud by UnfinishedLeaf zvěčil počet jak Leaf, tak UnfinishedLeaf, jenže ten dle defaultní implementace zvěčí akorat type(self), což je imho UnfinishedLeaf, tedy neni třeba odčítat.

Vůbec byto chtelo tydle county zrevidovat a ujednotit. (Psal je Pepa bez mýho čeku a ja tam v tu dobu psal paralelně ve svý větvi nějaký svoje počítáčky, který se s těma Pep_countama krejou.)