i was writing about code splitter (which breaks input text file on
logical lines) - this splitter i find very important thus i was
writing about it many times.... second important thing ius line
atomizer wchich in turn breaks logical line on atoms

and note i write on this as i find this not just a piece of code to discuss
but somethink that has somewhat scientific value... also i faind it quite
oryginal i guess.. people dont see write this way though for me this method
seems superior (at least in terms of clarity)

what i got is basic atomizer , this atomizer divides on alphanumeric words of various sized words and also returns punctuations, each pny by one
this if i would atomize

void foo(int x, int y) {
i would get such result

1: "void"
2: "foo"
3: "("
4 "int"
5 "x"
6 ","
7 "int"
8 "y"
9 ")"
10 ""{"

so this is only 2 types of atoms i would say

and on this i found the code of furia, i ommited quited literals "aaaaaas ss"
and ' djkj dkj' and this was mistake becouse i should add it yet. as a 3rd type of atom )
also i guess i should add things like that 23.67876 as a sole atom .. i aloso probably should add commentary pieces as another type of atom, also
i think if i should add $ and @ as an alphanumeric signs (could be part of
alphanumeric words , not be teken as sole operators/punctuation)
also think if not add #fffff as a sole atom (think i could take # as a hex prefix
shorter alternative to 0xfffff)

what else i could treat as a sole atoms you think?

the basic atomizer code is

chunk FindFirstAtom_4furia(chunk txt) //not generalized
{ chunk result = {0};

if(ChunkIsEmpty(txt))
return result;

int len = ChunkLength(txt);

/// find begining
int i;

for(i=0; i<len; i++)
{
if(IsWhiteSpace(txt.beg[i])) {
continue;
}

if(IsPunctuation(txt.beg[i])) {
result.beg = &txt.beg[i];
result.end = &txt.beg[i];
return result;
}

if(IsAlpha(txt.beg[i])) {
result.beg = &txt.beg[i];
goto find_alpha_atom_end;
}
}

return result; // begining not found

find_alpha_atom_end:

for(int j=i+1; j<len; j++)
{
if(IsAlpha(txt.beg[j])) {
continue;
}

if(IsWhiteSpace(txt.beg[j])) {
result.end = &txt.beg[j-1];
return result;
}

if(IsPunctuation(txt.beg[j])) {
result.end = &txt.beg[j-1];
return result;
}
}

result.end = &txt.beg[len-1];
return result;
}

chunks LineAtomizer4furia(chunk txt)
{

static chunk* internal_ram_for_chunks = NULL;

int chunks_number_reserved_storage = 1000;

internal_ram_for_chunks = (chunk*) realloc(internal_ram_for_chunks, chunks_number_reserved_storage * sizeof(chunk) );

chunks results = {0};

///////// collect them

chunk txt4scan = txt;

int n;

for( n=0; ; n++)
{
chunk atom = FindFirstAtom_4furia(txt4scan);
txt4scan.beg = atom.end + 1;

// printf("\n>>>");
// PrintChunk(atom);

if(ChunkIsEmpty(atom))
{
results.first = &internal_ram_for_chunks[0];
results.last = &internal_ram_for_chunks[n-1];

return results;
}

internal_ram_for_chunks[n] = atom;

if( n > chunks_number_reserved_storage ) //resize storage if need
{
chunks_number_reserved_storage*=4;
internal_ram_for_chunks = (chunk*) realloc(internal_ram_for_chunks, chunks_number_reserved_storage * sizeof(chunk) );
}
}

}

void TestFuriaAtomizer()
{ chunk ch = Chunk(" internal_ram_for_chunks = #22fa34e 0x44zfa3 0x32af2 3230z09 \"sass ass\" s 'aasdd2as asd' `sa d2 2#$` (chunk*) realloc(internal_ram_for_chunks, chunks_number_reserved_storage * 298728/ sizeof(chunk) ); ");
chunks atoms = LineAtomizer4furia(ch);
PrintChunks(atoms);

}

there is for example confusion for me what treat as a number chunk,
right now i just treat all alphanumeric particles as atoms, (like zzzz 1111 1zzz z111)
probebly i could treat those starting with digit 0-9 as number (including 1zzzzz)
and maybe all started with # also as numbers (not fully sure as to this)
#ff is for me better than 0xff (looks better and is shorter)
there is also problem with this dot if 1zzz is a number do atomize this dot as a part of a
number? 1zzz.zzz or treat it as 3 atoms? (and what with 1zz.zz.zz.z.zz ? ) 1.1 is number 1.a is probably a number a.a is 3 atoms i guess but a.1 is 3 atoms too? or maybe two?
this dot thing is specifically unclear imo

fir <profesor.fir@gmail.com> writes:
>there is for example confusion for me what treat as a number chunk,
>right now i just treat all alphanumeric particles as atoms, (like zzzz 1111 1zzz z111)
>probebly i could treat those starting with digit 0-9 as number (including 1zzzzz)
>and maybe all started with # also as numbers (not fully sure as to this)
>#ff is for me better than 0xff (looks better and is shorter)
> there is also problem with this dot if 1zzz is a number do atomize this dot as a part of a
>number? 1zzz.zzz or treat it as 3 atoms? (and what with 1zz.zz.zz.z.zz ? ) 1.1 is number 1.a is probably a number a.a is 3 atoms i guess but a.1 is 3 atoms too? or maybe two?
>this dot thing is specifically unclear imo

Rather than re-inventing the wheel, why don't you just use
lex(1) to generate your tokenizer?

DIGIT [0-9]
ID [a-zA-Z_][a-zA-Z0-9_]*

%%

{DIGIT}+ {
push_uint64(yyextra, strtoul(yytext, NULL, 10));
}

0[xX][0-9a-fA-F]+ {
push_uint64(yyextra, strtoul(yytext, NULL, 16));
}

n[0-9]"."[a-zA-Z0-9_]+"["[0-9]"]" {
push_identifier(yyextra, yytext);
}

{ID} {
push_identifier(yyextra, yytext);
}

"+"|"-"|"*"|"/"|"%"|"<<"|">>"|"&"|"|"|"^"|"=="|"!="|"<="|">="|"<"|">"|"=" {
push_opname(yyextra, yytext);
}

"(" {
push_lparen(yyextra);
}

")" {
push_rparen(yyextra);
}

środa, 27 kwietnia 2022 o 18:05:50 UTC+2 Scott Lurndal napisał(a):
> fir <profes...@gmail.com> writes:
> >there is for example confusion for me what treat as a number chunk,
> >right now i just treat all alphanumeric particles as atoms, (like zzzz 1111 1zzz z111)
> >probebly i could treat those starting with digit 0-9 as number (including 1zzzzz)
> >and maybe all started with # also as numbers (not fully sure as to this)
> >#ff is for me better than 0xff (looks better and is shorter)
> > there is also problem with this dot if 1zzz is a number do atomize this dot as a part of a
> >number? 1zzz.zzz or treat it as 3 atoms? (and what with 1zz.zz.zz.z.zz ? ) 1.1 is number 1.a is probably a number a.a is 3 atoms i guess but a.1 is 3 atoms too? or maybe two?
> >this dot thing is specifically unclear imo
> Rather than re-inventing the wheel, why don't you just use
> lex(1) to generate your tokenizer?
>
> DIGIT [0-9]
> ID [a-zA-Z_][a-zA-Z0-9_]*
>
> %%
>
>
> {DIGIT}+ {
> push_uint64(yyextra, strtoul(yytext, NULL, 10));
> }
>
> 0[xX][0-9a-fA-F]+ {
> push_uint64(yyextra, strtoul(yytext, NULL, 16));
> }
>
> n[0-9]"."[a-zA-Z0-9_]+"["[0-9]"]" {
> push_identifier(yyextra, yytext);
> }
>
> {ID} {
> push_identifier(yyextra, yytext);
> }
>
>
> "+"|"-"|"*"|"/"|"%"|"<<"|">>"|"&"|"|"|"^"|"=="|"!="|"<="|">="|"<"|">"|"=" {
> push_opname(yyextra, yytext);
> }
>
> "(" {
> push_lparen(yyextra);
> }
>
> ")" {
> push_rparen(yyextra);
> }
im rather inventyng new wheel then reinventing old i guess - and thats a bit of
difference
i dont know what this yaxx is, always seem too boring to learn but if someone want
to talk something i may read

this splitter+atomizer (based on chunks) approach is especially good for some reasons imo,
(bit sad i not invented something new from the time i wourked out thi splitter+atomizer and
it was already few years ago)

fir <profesor.fir@gmail.com> writes:

> what i got is basic atomizer , this atomizer divides on alphanumeric
> words of various sized words and also returns punctuations, each pny
> by one this if i would atomize
>
> void foo(int x, int y) {
> i would get such result
>
> 1: "void"
> 2: "foo"
> 3: "("
> 4 "int"
> 5 "x"
> 6 ","
> 7 "int"
> 8 "y"
> 9 ")"
> 10 ""{"
>
> so this is only 2 types of atoms i would say
>
> and on this i found the code of furia, i ommited quited literals
> "aaaaaas ss" and ' djkj dkj' and this was mistake becouse i should add
> it yet. as a 3rd type of atom ) also i guess i should add things like
> that 23.67876 as a sole atom .. i aloso probably should add commentary
> pieces as another type of atom, also i think if i should add $ and @
> as an alphanumeric signs (could be part of alphanumeric words , not be
> teken as sole operators/punctuation) also think if not add #fffff as a
> sole atom (think i could take # as a hex prefix shorter alternative to
> 0xfffff)
>
> what else i could treat as a sole atoms you think?

That depends on your objectives, but even for a simple subset of C you
should probably recognise sequences like ++, --, += (etc), ..., ->, <<
and so on being single tokens.

As for numbers, "1ull" is a number in C as are "0x.1P-1" and "1f". And
in C20 so is ".0dd".

--
Ben.

środa, 27 kwietnia 2022 o 18:28:17 UTC+2 Ben napisał(a):
> >
> > what else i could treat as a sole atoms you think?
> That depends on your objectives, but even for a simple subset of C you
> should probably recognise sequences like ++, --, += (etc), ..., ->, <<
> and so on being single tokens.
>

i thinked of it (becouse i also see that most of the punctuation marks work alone but some ot them work like two ++ -- // += etc) but this eventually is not so good idea (im stil not sure) this is becouse if i check
in later code things like atom[i]=='+' writing atom[i]=='+' && atom[i+1]=='=' is not so harm and fact
that i can assume all punctuations are 1 char long not gives me more in that further code, I am not sure
though but for now i decided not do that (if i would do that i would generally do more on that atom level
not few '++' and for now i didnt seen how more i can do - this is hovever some thing for consideration)

normally after this 1 plitter/log-line layer and 2 atoms layer i go stright to if's (small or big how to say it) forest hovvever i noticed recently i would need possibly yet something among atoms and ifs, at the moment hovever im not sure how to name it - it is for example a piece of code that would present an
expressions for me like in function callargument list
boo(x+x+2, foo(a+b/2,f()*3+zise,7*foo2.z.z.3) );

i got a code that emits assembly for expresions (right now only simple) but here like above i got 4 of them so it seems i need maybe some 3rd layer after splitter and atomizer hovever im not sure yet what to think on this, maybe its a kind of 'unwinder' (?) (code that unwind things and produce sequential list?)
got no much idea but there is the think that atom level just should produce atoms in a form that next layer would get as most simple to operate (and for sure giving "akjhsakjh21298&^%&^" as a sole atom is very helpful here, same with 23.233d numbers giving ++ as a sole gives much less..still its kinda unclear
i agree...++ goes in opposite direction (or at least it may be seen that it goes) kinda as atommiser broke things on atoms then some next layer could reckognize particules like this ++ or foo2.z.z.3 above (whatever it is z.3 could be seen as a shortkut for z[3] eventually or a field of structure if structure could permision to mame fields with a numbers)

> As for numbers, "1ull" is a number in C as are "0x.1P-1" and "1f". And
> in C20 so is ".0dd".
>

some conservative wiew would be treat number as alphanumeric begining with digit or dot and having
at most one dot in it

this eventually hovever leads to existence of bad atoms ..i dont ermember but in my simple splitter bad atoms do not exist becouse yopu ony got 2 kind of them either 1-sized punctuation symbol or n-sized alphanumeric ..now it would yeild to bad weird atoms too

> --
> Ben.

środa, 27 kwietnia 2022 o 19:09:51 UTC+2 fir napisał(a):
> środa, 27 kwietnia 2022 o 18:28:17 UTC+2 Ben napisał(a):
> > >
> > > what else i could treat as a sole atoms you think?
> > That depends on your objectives, but even for a simple subset of C you
> > should probably recognise sequences like ++, --, += (etc), ..., ->, <<
> > and so on being single tokens.
> >
> i thinked of it (becouse i also see that most of the punctuation marks work alone but some ot them work like two ++ -- // += etc) but this eventually is not so good idea (im stil not sure) this is becouse if i check
> in later code things like atom[i]=='+' writing atom[i]=='+' && atom[i+1]=='=' is not so harm and fact
> that i can assume all punctuations are 1 char long not gives me more in that further code, I am not sure
> though but for now i decided not do that (if i would do that i would generally do more on that atom level
> not few '++' and for now i didnt seen how more i can do - this is hovever some thing for consideration)
>
> normally after this 1 plitter/log-line layer and 2 atoms layer i go stright to if's (small or big how to say it) forest hovvever i noticed recently i would need possibly yet something among atoms and ifs, at the moment hovever im not sure how to name it - it is for example a piece of code that would present an
> expressions for me like in function callargument list
> boo(x+x+2, foo(a+b/2,f()*3+zise,7*foo2.z.z.3) );
>
> i got a code that emits assembly for expresions (right now only simple) but here like above i got 4 of them so it seems i need maybe some 3rd layer after splitter and atomizer hovever im not sure yet what to think on this, maybe its a kind of 'unwinder' (?) (code that unwind things and produce sequential list?)
> got no much idea but there is the think that atom level just should produce atoms in a form that next layer would get as most simple to operate (and for sure giving "akjhsakjh21298&^%&^" as a sole atom is very helpful here, same with 23.233d numbers giving ++ as a sole gives much less..still its kinda unclear
> i agree...++ goes in opposite direction (or at least it may be seen that it goes) kinda as atommiser broke things on atoms then some next layer could reckognize particules like this ++ or foo2.z.z.3 above (whatever it is z.3 could be seen as a shortkut for z[3] eventually or a field of structure if structure could permision to mame fields with a numbers)
> > As for numbers, "1ull" is a number in C as are "0x.1P-1" and "1f". And
> > in C20 so is ".0dd".
> >
> some conservative wiew would be treat number as alphanumeric begining with digit or dot and having
> at most one dot in it
>
> this eventually hovever leads to existence of bad atoms ..i dont ermember but in my simple splitter bad atoms do not exist becouse yopu ony got 2 kind of them either 1-sized punctuation symbol or n-sized alphanumeric ..now it would yeild to bad weird atoms too
>
sorry if that was probably extremly hard to read

what i think is i need to balance clarity of rules and and usability of the outcome and those dotted numbers make problem here.. they are needed to be atoimised for usability but their form breaks clarity

for example im rather sure i shouldnt atomize a.b.c as one atom (becouse then i would need to split it again in compiler) but for sure i need 11.22 treat as one.. now things like 11.22ssz yeilds to extended number or bad atom (i would rather think is as extended number) but this 11.22ssz.3.s.s.s$zzz.z.z.33.@zz is rather for sure bad atom )or begining of this is number wrongly attached to series of atoms)... not sure how decision to take here

quotes also btw lead to bad atoms becouse im sure quotes should be always "aa jlk k " (begining and ending with quote mark) so aa"xx" or "aaa"z makes already bad atoms - so im not sure if i should make compile error or allow that?

środa, 27 kwietnia 2022 o 19:31:48 UTC+2 fir napisał(a):
> sorry if that was probably extremly hard to read
>
> what i think is i need to balance clarity of rules and and usability of the outcome and those dotted numbers make problem here.. they are needed to be atoimised for usability but their form breaks clarity
>
> for example im rather sure i shouldnt atomize a.b.c as one atom (becouse then i would need to split it again in compiler) but for sure i need 11.22 treat as one.. now things like 11.22ssz yeilds to extended number or bad atom (i would rather think is as extended number) but this 11.22ssz.3.s.s.s$zzz.z.z.33.@zz is rather for sure bad atom )or begining of this is number wrongly attached to series of atoms)... not sure how decision to take here
>
> quotes also btw lead to bad atoms becouse im sure quotes should be always "aa jlk k " (begining and ending with quote mark) so aa"xx" or "aaa"z makes already bad atoms - so im not sure if i should make compile error or allow that?

i will maybe do that way -> aa"xx" are two atoms aa and "xx"
11.22ssz.3.s.s.s$zzz.z.z.33.@zz i will treat as a number (it is idientifier is letters digits and _$@ number is the same but begins with digit and also may have dots. i forgot it also may have minus sign, and there is a question if to allow space among this minus and digit, i probably disalow that space)

treating this as a number seems just simpler than thinking when to cut it and if i would cut it on a second dot then seeing this rest as a numbers punctuations and identfiers glued together seems to weird

im not quite happy with that state of things as this is some mess imo

damn im not even sure of that maybe i should more strictly and treat only 11.22 abive as a number and that contained .3. as alphanumeric...damn problematic case

środa, 27 kwietnia 2022 o 19:57:36 UTC+2 fir napisał(a):
> środa, 27 kwietnia 2022 o 19:31:48 UTC+2 fir napisał(a):
> > sorry if that was probably extremly hard to read
> >
> > what i think is i need to balance clarity of rules and and usability of the outcome and those dotted numbers make problem here.. they are needed to be atoimised for usability but their form breaks clarity
> >
> > for example im rather sure i shouldnt atomize a.b.c as one atom (becouse then i would need to split it again in compiler) but for sure i need 11.22 treat as one.. now things like 11.22ssz yeilds to extended number or bad atom (i would rather think is as extended number) but this 11.22ssz.3.s.s.s$zzz.z.z.33.@zz is rather for sure bad atom )or begining of this is number wrongly attached to series of atoms)... not sure how decision to take here
> >
> > quotes also btw lead to bad atoms becouse im sure quotes should be always "aa jlk k " (begining and ending with quote mark) so aa"xx" or "aaa"z makes already bad atoms - so im not sure if i should make compile error or allow that?
> i will maybe do that way -> aa"xx" are two atoms aa and "xx"
> 11.22ssz.3.s.s.s$zzz.z.z.33.@zz i will treat as a number (it is idientifier is letters digits and _$@ number is the same but begins with digit and also may have dots. i forgot it also may have minus sign, and there is a question if to allow space among this minus and digit, i probably disalow that space)
>
> treating this as a number seems just simpler than thinking when to cut it and if i would cut it on a second dot then seeing this rest as a numbers punctuations and identfiers glued together seems to weird
>
> im not quite happy with that state of things as this is some mess imo
>
> damn im not even sure of that maybe i should more strictly and treat only 11.22 abive as a number and that contained .3. as alphanumeric...damn problematic case

it (i mean those dotted and negative numbers) makes so damn problem thet i got serious doubt if i should do that on this atomic layer for exampla take -11.22 this seems to be number but it depends also what as before and after like 11-11.22.3 etc ..this is so complex as to rules that maybe it sadly shouldnt be resolved here...maybe seems so (those cases seem to be proof that not, txis syntax is to bad to fit to this level - it would fit if number would have defnite form like in quites ( "asasa") opening quote, some signs ,ending quote and that type of quote would meen "that is a number " without that it is too mess

środa, 27 kwietnia 2022 o 20:23:08 UTC+2 fir napisał(a):
> >
> > damn im not even sure of that maybe i should more strictly and treat only 11.22 abive as a number and that contained .3. as alphanumeric...damn problematic case
> it (i mean those dotted and negative numbers) makes so damn problem thet i got serious doubt if i should do that on this atomic layer for exampla take -11.22 this seems to be number but it depends also what as before and after like 11-11.22.3 etc ..this is so complex as to rules that maybe it sadly shouldnt be resolved here...maybe seems so (those cases seem to be proof that not, txis syntax is to bad to fit to this level - it would fit if number would have defnite form like in quites ( "asasa") opening quote, some signs ,ending quote and that type of quote would meen "that is a number " without that it is too mess

finally i dont know...i wrote two wersions, one not glues 11.22 type atoms and other that does (with this previously mentioned rule if it srarts with digit it not takes dot as an end of an atom)

i would need to check what is more practical, it seem like this glueaing wersion could be more to use bot writing something GiveNumber(i) which will check if there is integer chunk or integer-dot-integer is probably not much more complex and the atom layer is cleaner so i dont know...it seems i got more will and skill to resolve this type of problems back then (maybe my head reshaped on less focused state)

fir <profesor.fir@gmail.com> writes:

> for exampla take -11.22 this seems to be number but it depends also
> what as before and after like 11-11.22.3 etc

No. In C, -11.22 is not a number, it's an operator followed by a number
(a floating point constant).

> ..this is so complex as to rules that maybe it sadly shouldnt be
> resolved here.

The generally accepted technique is to split the input into lexical
tokens and then apply a parser to that token stream.

All of these are well-understood problems with well-known and effective
solutions.

--
Ben.

środa, 27 kwietnia 2022 o 22:40:26 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > for exampla take -11.22 this seems to be number but it depends also
> > what as before and after like 11-11.22.3 etc
> No. In C, -11.22 is not a number, it's an operator followed by a number
> (a floating point constant).
> > ..this is so complex as to rules that maybe it sadly shouldnt be
> > resolved here.
> The generally accepted technique is to split the input into lexical
> tokens and then apply a parser to that token stream.
>
> All of these are well-understood problems with well-known and effective
> solutions.
>
sorta but not fully... they not use as far as i know the chunks resizable arrays also some
decisions how to see things i think may be different.. and note my goal is not to write compiler but to rethink some inner things in a way i see it

środa, 27 kwietnia 2022 o 23:19:57 UTC+2 fir napisał(a):
> środa, 27 kwietnia 2022 o 22:40:26 UTC+2 Ben napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > for exampla take -11.22 this seems to be number but it depends also
> > > what as before and after like 11-11.22.3 etc
> > No. In C, -11.22 is not a number, it's an operator followed by a number
> > (a floating point constant).
> > > ..this is so complex as to rules that maybe it sadly shouldnt be
> > > resolved here.
> > The generally accepted technique is to split the input into lexical
> > tokens and then apply a parser to that token stream.
> >
> > All of these are well-understood problems with well-known and effective
> > solutions.
> >
> sorta but not fully... they not use as far as i know the chunks resizable arrays also some
> decisions how to see things i think may be different.. and note my goal is not to write compiler but to rethink some inner things in a way i see it

specifically im not convinced they write compilers in such nice form like

main()
{ chunk d = LoadChunk(input_file_name);
chunks lines = SplitOnLogLines4Furia(d);
int n = ChunksLength(lines);
for(int i=0; i<n; i++)
{ chunk current_line = lines.first[i];
if(ChunkIsEmpty(current_line) continue;
chunks atoms = LineAtomizer4furia(current_line);
int atoms_len = ChunksLength(atoms);
if(atoms_len<1) continue;

//acces atoms for each line here, emit assembly
}

}

maybe im reinventing things, but i dont heard on this and see many people do text processing
in C much more worse way

this pice of code above shows btw how the clarity of this splitter produces and what atomizer produces is important in inner loop

this code is clean imo but the attempts to atomize numbers showed to be messy

im not sure if i will not get tired by this in this month and eventually get back to it in future,
but if no maybe i will say something about those inner constructions in that inner loop
(whose now i got more like prototyped and badly written, but im not sure if some relatively clean schemes grow

for example from what i was posting some may seen thet there is a scheme of reallock
with static seed contained in function, so this work like resizable aray covered inside function
this seem to be a good candidate for such scheme

this way for example scanning pass when you need to build info on variables defined in
source could be done like

for(int i=0; i<n; i++)
{ AddVariableDefinition( FindVariableDefinition(current_line_atoms));
//say FindVariableDefinition returns int2 structure with numbers of atoms like "int" "size_x"
// (which i later nid for example when compiling expresions to know what is int and what is float

}

i find some sense in searching for such kind of 'streamline' patterns

czwartek, 28 kwietnia 2022 o 00:18:56 UTC+2 fir napisał(a):
>
> for(int i=0; i<n; i++)
> {
> AddVariableDefinition( FindVariableDefinition(current_line_atoms));
> //say FindVariableDefinition returns int2 structure with numbers of atoms like "int" "size_x"
> // (which i later nid for example when compiling expresions to know what is int and what is float
>
> }
>
this example is btw a bit fictional as i got such code for scaning this variables (and this is a piece of cace to be written in half an hour or something like that) but in reality this FindVariableDefinition not returns the info but calls inside AddVariableDefinition in couple of places of its inner tree (this is for example becouse it also gets track what current scope of function it is which it also reckognizes (wchich is trivial)

all in all im not sure what comes from this fictional example, if nothing or something...if that piece of code cant be shaped this way maybe it may be shaped other streamlined way ... all in all what i find interesting is those finding ways to shape code nice way and maybe i will find something interesting yet

> i find some sense in searching for such kind of 'streamline' patterns

feeling my head partially went back old ways on thinking on c again (partially)
could say that after splitter and atomizer i need this one thing mentioned here
which i would name expression digger (so you got 3 splittr atommizzr diggr)

this is becouse in this proto-c code i got i got generali lines of defnitions and lines of calls
so its like
d c
c d
d c
c c
d and so on (when call may be allo a call to entity not only function, like 1,2,3,a,foo() all are calls)

some extension on this is (those punctuation mark based) expresions
but even before then the extension is a what i could name list/vector
it is a way to post a vector of calls and definition in one line so this yeald
to need to write an expression digger which takes chunks and return list of subchunks

need to get a bit more clear on this (in my code)

niedziela, 1 maja 2022 o 14:57:28 UTC+2 fir napisał(a):
> feeling my head partially went back old ways on thinking on c again (partially)
> could say that after splitter and atomizer i need this one thing mentioned here
> which i would name expression digger (so you got 3 splittr atommizzr diggr)
>
> this is becouse in this proto-c code i got i got generali lines of defnitions and lines of calls
> so its like
> d
> c
> c
> d
> d
> c
> c
> c
> d
> and so on (when call may be allo a call to entity not only function, like 1,2,3,a,foo() all are calls)
>
> some extension on this is (those punctuation mark based) expresions
> but even before then the extension is a what i could name list/vector
> it is a way to post a vector of calls and definition in one line so this yeald
> to need to write an expression digger which takes chunks and return list of subchunks
>
> need to get a bit more clear on this (in my code)

the fourth thing/stage after the splitter atomizer digger i could probably name as
microcompiler - it just compiles what was dug