BASED.md

@@ -62,9 +62,9 @@ Meg ez is (basic block-os módszer):
 ^^Ezek "kezelik" a memóriákat és resource-okat RAII-módon, konstruktorral és destruktorral.
 Szerintem a struct-hoz és class-hoz képest is jobb szó.
 
-Lesz továbbá tagged union is - lásd lejjebb - és interfészek.
+Lesz továbbá tagged union is - lásd lejjebb - és interfészek (ami tagged union-á fordul le, hacsak ki nem optimizálja a fordító).
 
-Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni??? Esetleg nem is ilyen <..> stílusban?
+Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni???
 
 # Placement new
 
@@ -414,10 +414,6 @@ Lásd még:
 
 ui.: Ha nem lesz operátor overload, akkor szerintem legyen több dimenziós tömb (nem a tömbök tömbje, hanem: matrix[15, 10, 42] = 5;
 
-### restrict-ált tömbök
-
-A tömbökre is kell a pointerekhez hasonló restrict.
-
 ## Típusos indexek
 
 Egy pointer a modern gépen 64 bit, sokszor tömörebben tudsz tárolni "referencia-szerűséget" ha indexet tárolsz rá!
@@ -783,24 +779,68 @@ minden esetre kell legyen definíciója, vagy az únió eseteitől függetlenül
 Zsolt vetette fel, hogy neki azért öröm töltené el a szívét, ha lehetne egy "kicsit OO style" azért annyiban, hogy egy tömbben tud
 keverni különböző típusú dolgokat, amiknek közös az interfésze és kapni ilyeneket függvény paraméterként...
 
-**Megoldás**
+Ez valamilyen szinten jogos elvárás és az únió részben tudja is ezt, mert csinálhat az ember egy tagged union-t amiben ő maga
+sorolja fel így a típusait amik a tömbben lesznek és a fun() függvényeikben simán this->fun() átírányít / delegál akkor.
 
-Lásd tagged union-oknál a "negyedik változat". Szerintem ez a legszebb!!! A tagged union tud implementálni interfészt és így
+No de! Ennél tudunk jobbat is! Mert ez nem kezeli azt az esetet, ha egy library-t akarok írni és ezt forrással együtt kiadni!
-sokkal egzaktabban történik ugyanez "háttérben titkos tagged union generálás nélkül" - na így lett letisztult!
+Ugyanis olyankor a lib írójaként én megszabom mely dolgokat veheti fel a tagged union - tehát előre kéne tudnom a use case-eket!
+Ez nincs így! Ellenben a fordítót kihasználhatjuk arra, hogy generálja ezeket a tagged union-okat le, az alapján, hogy kik
+implementálnak egy interfészt!
 
-+ a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is! Emiatt elvileg generic se kéne!
+Első változat:
+
+    interface IStringifyable {
+        string stringify();
+    }
+
+    handle A implements IStringifyable {
+       ... 
+    }
+
+    handle B implements IStringifyable {
+       ... 
+    }
+
+    // Ez ilyenkor egy tömb, aminek az elemei igazából tagged union elemek,
+    // a build-ben meglévő összes azt implementáló dolog alapján...
+    void process(IStringifyable arr[]) {
+        ...
+    }
+
+Megj.: Szerintem ettől generic-szerűbb lesz a dolog, ha típusnak generik paraméternek adható egy "interfész"!
+       Olyankor csak konkrétan az interfész nevével (vagyis nem T implements IAkarmi, csak simán IAkarmi, de kiírható (ha 2 kell).
+       Továbbá simán amikor függvény paraméternek használjuk, akkor lehessen rajta "constexpr elágazni" a típusán!
+
+Vagyis írhatunk ilyeneket:
+
+handle<IStringifyable, IStringifyable2 implements IStringifyable> {
+    ...
+}
+
+Vagy akár ilyet is (bár ezt kevéssé javaslom, de hasznos lehet):
+
+    void process(IStringifyable arr[]) {
+        switch(add.elemtype) {
+            case A:
+                ...
+            case B:
+                ...
+        }
+    }
+
+Ifelni is lehet - olyankor például csak egy adott típusra valami speciális pluszt adni, kezelendő esetet...
+
+Második változat:
+
+    Lásd tagged union-oknál a "negyedik változat". Szerintem ez a legszebb!!! A tagged union tud implementálni interfészt és így
+    sokkal egzaktabban történik ugyanez "háttérben titkos tagged union generálás nélkül" - na így lett letisztult!
+
+    + ha nem tömbről van szó, akkor a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is (kell-e vajon?)
 
 Az interfészekre lehet többszörös öröklődés (egymás közt is, meg itt is).
 
 FONTOS: A shared object-ek között NEM ajánlódnak ki ilyen jellegű típusok! Csak rekordok!
 
-Megj.: A második változat (tagged union-os megoldás) kell szerintem + lehessen handle interfészelés!
-       Tehát egy handle is "implementálhat" interfészt és olyankor generikus kód keletkezik majd.
-       Ennél azt is szeretném, ha "tömbre" is működne, tehát IGameObject stuff[] paraméterrel a függvény
-       a hívási pontok alapján többféle módon is generatívan generálódik. Szerintem talán ki kell írni
-       ott, hogy IGameObject-like és interfész "like-olása" mindig ezt jelentené?
-       FONTOS: Adattagnak így nem lehet "interfész" típusa, csak tagged union-os esetben ugyebár...
-
 ## Láthatóság
 
 TODO: Egyszeűsítendő?
@@ -1488,20 +1528,20 @@ Máshonnan elérni így lehet, namespace-elés szerűen:
 
 Ha nem szerepel több szó a definíciós első sorban az enter előtt / zárójelek előtt, akkor csak kódot tartalmazó "funkcionális" szó:
 
-    #: just_code
+    #: #just_code
       #dup
       #inc
       #swap
     #
 
     #push(12)
-    just_code
+    #just_code
     #intprint // 12
     #intprint // 13
 
-Vagy(zárójelen belüli futásra):
+Vagy:
 
-    #: just_code (
+    #: #just_code (
       #dup
       #inc
       #swap
@@ -1617,7 +1657,6 @@ Ezt követően hívható a szó prefixelt változata
     #intprint // 4
 
 Megj.: A #builtin esetben mindig van elég byte hely majd a parzernek helyben átírni a szót a megfelelőre (whitespace-es törléssel)
-Megj.: Erre nem kell külön runtime type - ezt lehet simán a deklarációkor helyben átfordítani!
 
 ## Névtelen szó - mégsem lesz!!!
 
@@ -1704,7 +1743,6 @@ szöveges interfésszel, hanem simán csatornákkal és egy DAG-ot leírva, azé
         char name[]; // inline! Tehát nem egy pointer! Zero terminált a whitespace / zárójel felülírásával.
         char vars[]; // inline! Maga a tárhely is itt lesz! Elfér 4 byte ' @i,' vagy ' @j<EOL>' miatt!
         char data[]; // inline! Előbb a változók, aztán a kód - így írható primitív forth-szavakkal is kódszó (pl. outputra).
-        char ender[]; // inline!
     };
 
 A szavakat az "ender" string terminálja, a hosszt itt alapból nem tároljuk. Amikor a parzer látja
@@ -1727,38 +1765,34 @@ hasonló dolgokon túl! Amikor az első hívás történik, akkor megpróbáljuk
 ideiglenes tárhely sem szükséges, csak egy plusz számítási menet, amikor még NEM csináljuk meg, csak kiszámoljuk mibe
 kerülne és mennyi ram kell hozzá - kifér-e majd a jelen dolog helyére! Ha igen, akkor átírjuk + használjuk a stack-et.
 
-Flag-ek (flags):
+Flag-ek:
 
     0. offset_top
     1. offset_top
     2. offset_top
     3. offset_top
-    4. offset_top
+    4. DEF_TYPE0: definíciós típus első bitje
-    5. offset_top
+    5. DEF_TYPE1: 00: reguláris szó, 01: insertálóként definiált szó
-    6. WORD_TYP0: a típus első bitje
+    6. TYPE0: a típus első bitje
-    7. WORD_TYP1: a típus második bitje
+    7. TYPE1: a típus második bitje (00 - szöveg és futtatatlan, 01 - szöveg és futtatott, 10 - THREADED, 11 - internal (C ptr)
 
-    enum SLC_WORDTYP {
+EDIT:
-        SLC_WORDTYP_TEXT = 0,
-        SLC_WORDTYP_NATIVE = 1,
-        SLC_WORDTYP_THREADED_SESSION = 2,
-        SLC_WORDTYP_THREADED_INLINE = 3,
-    };
 
+    Jelenleg úgy néz ki, hogy itt hét bitet is használhatnék - kérdés kéne-e vagy legyen még valami flag ott, mondjuk
+    egy továbbfejlesztési lehetőségként. Szerintem az utóbbi és akkor a data[] inline helyett a hossz után ptr lesz!  
 
 Mi az a "threaded kód"?
 
-    A "threaded kód" lényegében karaktersorozat helyett egy uint32_t-sorozat, ahol szavak helyett indexek vannak
+    A "threaded kód" lényegében karaktersorozat helyett egy uint32/64_t-sorozat, ahol szavak helyett indexek vannak
-    az adott szavak definíciós pontjaira - DE! Viszont a zárójelek is el vannak kódolva (spéci uint32_t-ként)
+    az adott szavak definíciós pontjaira - DE! Viszont a zárójelek is el vannak kódolva. Alapvetően uint32_t, de
+    a felső bit ha beáll akkor uint64_t kell két egymást követőt értelmezni (alsó 32 bit jön előbb módon!)
 
-    Ettől jellemzően tömörebb és hatékonyabb lesz az interpretálás hiszen nem kell szöveget parzolni,
+    Ettől jellemzően tömörebb és hatékonyabb lesz az interpretálás hiszen nem kell szöveget parzolni, nincs szótár lookup!
-    nincs szótár lookup, viszont megeshet, hogy "nincs elég hely" tárolni az adatokat a forrás szöveg helyén
+    Viszont megeshet, hogy "nincs elég hely" tárolni az adatokat a forrás szöveg helyén és nem optimalizálható olyankor...
-    és vagy nem optimalizálható olyankor, vagy amit mi csinálunk: a session storage-be tesszük az adatot...
 
-    Érdekes elképzelés lehet egy kifejezetten UTF8-szerű encoding is, hogy lehetőleg 8-16-32 bitet használjunk csak / szó!
 
-FONTOS: A threaded kódot megpróbáljuk a lehető leghamarabb "process-álással" generálni a session-be, de ha nem tudjuk azonnal
+    Érdekes elképzelés lehet egy kifejezetten UTF8-szerű encoding is, hogy lehetőleg 8-16-32-64 bitet használjunk csak / szó!
-        a függőségek miatt, akkor ugyebár valamit tennünk kell, addig marad ahogy van...
+    Szerintem ez fontos lenne, hogy az optimalizációt többször hajthassuk végre és ne csak hosszú szavakat használó esetben!
 
 Mint az egyértelmű, a szó deklaráció a kód szövegben legalább 4 byte-ot igénybe vesz és minden változó-deklarálás is!