as im being accused on talkin not on topics
(partially it may be true but its from practical reasons, i often
do and think on more standard c sometimes im focused on deeper c)


note hovever discussing c extensions and ideas is quite regular and
natural in this group i only did possibly more of this than anybody
(or most)


for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal modularity"
(or "hipermodularty) in wider scope realizes this

i began to think on this becouse wider hipermodularity in fact im sure
is right way but yeilds to some harder decisions becouse many things are
yet not clear so maybe i think i could consider /rethink this more
narrow scope to get for some conclusion - see for example this

this kinda proves that

1) functions in functuions finally shows to be good idea
2) its quite close if adding it to objects as in oop
(not fully as many impelenetationsof this oop (wth this
net of pointers) is total trash i eman on this more proper
"entity" form of objects (this entity form i personally usualy name as
module, but it also could be named repaired object in short object)

float* f = new float; //oop trash way
float f; //'entity' way/right way/c way (in this way f could be named
as object imo or module )



so the example


int print(char*txt)
{

int n = printf(txt);

chars+=n;
calls++;

return n;

static int calls = 0;
static int chars = 0;

float average() { return float(chars)/calls;}
void printf_average() { printf("calls %d, chars%d, average chars on
call %f ", calls, chars, average() ); }
void reset() {calls =0; chars =0;}
};


this alone maybe not opens so many questions, some may just use it
on c standard rules

main()
{
print("sdsdssfd");
print("sdsdsddsdsfd");

print. printf_average();

}

evenyually someone could ask if to add a parent function name prefix
here as obligatory

print. printf_average(); //this ?
print printf_average(); //this ?
printf_average(); //or this?

in my opinieon (but not decisive/final only for the consideration at the moment) probably all 3 should be allowed

probably in this moment

1) usability of this functions in functions is clear
2) not much language problems arise

BUT THE GENERALISATIONS of it (i mean draggging that functions into
being treated as a structure NOW MANY PROBLEMS arise (and on this maybe
later)















--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

as im being accused on talkin not on topics
(partially it may be true but its from practical reasons, i often
do and think on more standard c sometimes im focused on deeper c)

note hovever discussing c extensions and ideas is quite regular and
natural in this group i only did possibly more of this than anybody
(or most)

for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal modularity"
(or "hipermodularty) in wider scope realizes this

i began to think on this becouse wider hipermodularity in fact im sure
is right way but yeilds to some harder decisions becouse many things are
yet not clear so maybe i think i could consider /rethink this more
narrow scope to get for some conclusion - see for example this

this kinda proves that

1) functions in functuions finally shows to be good idea
2) its quite close if adding it to objects as in oop
(not fully as many impelenetationsof this oop (wth this
net of pointers) is total trash i eman on this more proper
"entity" form of objects (this entity form i personally usualy name as module, but it also could be named repaired object in short object)

float* f = new float; //oop trash way
float f;ÿÿ //'entity' way/right way/c way (in this way f could be named
as object imo or module )

so the example

int print(char*txt)
{

ÿ int n = printf(txt);

ÿ chars+=n;
ÿ calls++;

ÿ return n;

ÿ static intÿ calls = 0;
ÿ static intÿ chars = 0;

ÿ float average()ÿÿÿ {ÿ return float(chars)/calls;}
ÿ void printf_average() {ÿ printf("calls %d, chars%d, average chars on
call %f ", calls, chars, average()ÿ ); }
ÿ void reset() {calls =0; chars =0;}
ÿ};

this alone maybe not opens so many questions, some may just use it
on c standard rules

main()
{
ÿprint("sdsdssfd");
ÿprint("sdsdsddsdsfd");

ÿprint. printf_average();

}

evenyually someone could ask if to add a parent function name prefix
here as obligatory

ÿprint. printf_average(); //this ?
ÿprintÿ printf_average(); //this ?
ÿprintf_average();ÿ //or this?

in my opinieon (but not decisive/final only for the consideration at the moment) probably all 3 should be allowed

probably in this moment

1) usability of this functions in functions is clear
2) not much language problems arise

BUT THE GENERALISATIONS of it (i mean draggging that functions into
being treated as a structure NOW MANY PROBLEMS arise (and on this maybe later)

note also different example (not checked form compile errors just from
head with no checking)


note i aslo say on thsi as this wide hipormodularity may be too
ambitious but the aspect of this down here is alos interesting at it may
yeild to soem observations


int* tab2d(int w, int h)
{
width = w;
height =h;
tab = realloc(tab, width*height);

return tab2d;

static unsigned width;
static unsigned heighet;
static int* tab = NULL;

void set(int x, int y, int value) { tab[y*width +x] = value; }
int get(int x, int y) { return tab[y*width +x];; }


}
main
{

tab2d(10,10);

for(int i=0; i<300; i++)
set(rand()%width, rand()%height, rand()%200);
//or tab[y*width +x] = value;

tab2d(80,80);
}

it seem to have sense for me ...but why it dont work?

just becouse inside statics are not accesible in outside
(so it sorta whowy my very old idea of accesible statics and
idea of inner functions are more than compatible)

some could say that this way of coding wil make name pollution

(as for example width and haight inside function or
set() get(0 functions are to call from everywhere but it may be
resoleved at least 2 way

1) some may use this prefix like tab2d.set()

2) soem even could say that thise inner functions are avalieble only in
these functions (or down the branch?) (i would need to rethink it) where
the mother function is called (so if both functiond f(0 and g() have
fieldt set(0 and get()

then

main()
{
g(20,20);

set(2,3,88);//would call the g.set() becouse g is here called not f()
(if both you would need use a prefix)

}

NOTE this what i say here are only narrow pice of general
hypermodularisation which has harder problems











--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

note yet one thing

in c you have either scope global or local

here you git such case

main()
{
tab2d(); //allocks 2d tab and its accesible from here phisically
though tab2d definition is globally accesible (but in definition ram
pointer is NULL)
}

this may be an error i mean meybe definition shouldnt be globbally
accesible only as something to instantiate and tab2d in fact only should
be accesible after instantiation/allocation

(this observation was also in my previous thread on "fractal death")

btw c++ does something like this byt it allocks this tab2d with a
pointer which it in turn pass down the tree to subfunctions
(which is silly)


as to this acces in subfunctions i dont know - - if there is no
global space (except instantiation) it seems subfunctions need see
those objects of their superfunctions on the fly (with no passing
pointers just scope thing


howewer im not sure if it make sense becoys say i instantiate
given 'object' (module/function) in one branch but i need it
in parallel branch than what? instantiate it up the tree or
add some mechanism parrallel to instantation?


OR allow global space to SOME modules?

(like this print example - print seem to have global space for anyone
able o use it..but tab2d seems it should not be in global space for
only those could use it who are physically AFTER its instantation

its not clear yet to me




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

note yet one thing

in c you have either scope global or local

this third scope i eventually consider could be maybe named
branch scope (c++ realizes that (afaik as i weakly know c++)
by passing pointer to scopes of subfunctions thus extending
visibility on N ocal scopes )

normally the branch scope could be guarded quite statically,
just down the branch with no pointer passing - but as for now as i said
im not sure

1)if branch scope is really needed
2) how much needed is limitation of global scope

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

i may add yet some thing

(note i know probably nobodu understands what i say, though
maybe some understands maybe some parts of it)

note if i 'realize' such 'objests' as a 2d array
as functions - like

main()
{
tab2d(20,20) ; //tab2d fields and functions now awaliable
}
AND it showed it may be qith kinda sense to be done this way

then i could have need 2 or more tables not one


and if you use functions to it then you only has one function
here

related things make me think if i am saying that 4 things unify in one

1) source code modules
2) structures
3) functions
4) fundamentals (decided to maybe name builti types as inf float as fundamentals to have more solid name on this)

then maybe i should add alos types

becouse what is type like definition of structure type?
its a structure that uses zero ram

if function ddefinition would usezero ram function definition is also a type... and as there is maybe a NEED for those modules/functions/structures/fundamentals to be present in zero ram
variation
then maybe them also can be aligned with types

1) so in fact probably its okay to say that this unification also is
about types
2) the zero-memory versions of modules/functions are probably needed

(as you for example want to attach big module definition tou your code
but you dont want it to consume ram yet - also the option to have zero
ram modules/functions disables global scope of them

as if you only have zero ram definition in global scope its yet no
global visibility of 'entity' you need to first instantiate it and
local instance has local scope)



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

i also may add for some reason i dislike types
(i once sorta noticed that but for now i cant and want even remember the reason) now it seem to me that what is called type better to see as
"zero ram" version of given entity but for the sake of simplicity
i even could name those zero tam versions as 'types' (though
linguistically this is probbaly bad name those types)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal
modularity" (or "hipermodularty) in wider scope realizes this

It?s called ?nested functions?. The GNU C compiler already has this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk, which
is usually created on the stack. This requires an executable stack.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro pisze:

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal
modularity" (or "hipermodularty) in wider scope realizes this

It?s called ?nested functions?. The GNU C compiler already has this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk, which
is usually created on the stack. This requires an executable stack.

interesting, i didnt knew that

but it seems it doesnt work as it should

in cas im talking about those inner functions

1) has visibility as it was not inner (like normal)
2) but can be alos prefixes by his mothers name (this way you may define
many functions with the same name)

3) has acces to ststic fields of his mother (though ststic fields imo
also should be just visible outside

so as static fields also may have the same names in may functions maybe
there is analogy of thise inner functions and ststic fields/variables



4?) there is also a question if those functions can be callable only
down the branch i mean

foo()
{
static int* p = NULL;

f();


f()
{
p= realloc(p, 2000);
}


}


bar()
{
f();// ????this probably shouldnt compile as f is not down the branch
here (i not rethinked it yet fully)
}

main()
{
bar();
foo() ;;

}


if so there would be third kind of scope 1) global 2) local 3)
down-the-branch

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

foo()
{
ÿ static int* p = NULL;

ÿ f();

ÿf()
{
ÿ p= realloc(p, 2000);
}

}

wel this example is a bit flawed it should be

foo(int n)
{
static int* p = NULL;
p= realloc(p, 2000);

f();


f()
{
//uses p
/so in fact it have sense that only functions down the branch of foo
//could call it
}


}

bar()
{
ÿ f();// ????this probably shouldnt compile as f is not down the branch here (i not rethinked it yet fully)
}

main()
{
ÿ bar();
ÿ foo() ;;

}

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

fir pisze:

foo()
{
ÿÿ static int* p = NULL;

ÿÿ f();


ÿÿf()
{
ÿÿ p= realloc(p, 2000);
}


}

wel this example is a bit flawed it should be

foo(int n)
{
ÿÿ static int* p = NULL;
ÿÿ p= realloc(p, 2000);

ÿÿ f();

ÿ f()
ÿ{
ÿ //uses p
ÿÿ /so in fact it have sense that onlyÿ functions down the branch of foo
ÿÿ //could call it
ÿ}

ÿ}

bar()
{
ÿÿ f();// ????this probably shouldnt compile as f is not down the
branch here (i not rethinked it yet fully)
}

main()
{
ÿÿ bar();
ÿÿ foo() ;;

}

local variables could also have maybe down the branch scope
and there is also an theoretical option if global objects being
zero-memory and only have down the branch scope......alos local scopec
could be turned (opened) into down the branch

not saing it has a sense just for consideration

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 17/09/2026 04:03, Lawrence D?Oliveiro wrote:

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal
modularity" (or "hipermodularty) in wider scope realizes this

It?s called ?nested functions?. The GNU C compiler already has this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk, which
is usually created on the stack. This requires an executable stack.

That is not entirely accurate, but it does touch on an important point.

"Pure" nested functions that do not involve captures of non-constant and non-static local data can always be implemented exactly like a normal function. And that is exactly what gcc does when it can - the function
is a generated as a normal function but with special scope rules.

If you have :

int foo(int x) {
static int a;
const int b = 123;
constexpr int c = 456; // C23
extern int d;
int e;

int nested(int z) { return ... ; }
}

The body inside "nested" can access any of a, b, c, or d without any complications - all that is needed is some playing around of scopes, and compilers can handle that without trouble. A function like that can be implemented as a normal function, and is directly convertible to a corresponding function pointer. No trampolines are necessary.

Accessing "e" or "x" is more complicated - these are "captured by
reference". (For gcc's nested functions, capturing is always by
reference, never by value.) You can imagine that the nested function
gets some additional hidden parameters that are pointers to "e", "x",
and any other captured data.

Even then, trampolines are not generated unless the function is exported
in some way. That means the function "nested" in the example above is converted to a "int (*)(int)" function pointer and passed to another
function or returned from the surrounding "foo" function. (That would
have a very high risk of accessing data that no longer exists, which is
a bad idea!)

So to need trampolines of any sort, a nested function has to have
captures to non-static function local data that is not known to be
constant at compile time, and the address of the nested function has to
be passed out of the enclosing function. Clearly, a great many uses of
local functions are therefore not going to need trampolines at all.

Some platforms apparently use "descriptors" instead of executable
trampolines, where these "descriptors" are just data. And gcc supports "-ftrampoline-imp=heap" to put executable trampolines in heap memory
rather than the stack, so that you do not need an executable stack.

There is a warning flag, "-Wtrampolines", that tells you if a
stack-based trampoline is created. So "-Werror=trampolines" will
disable stack-based trampolines entirely.

Of course, the compiler will also typically try to inline the nested
functions where possible.


In C++, there is a strong similarity to lambdas. A lambda needs a
capture structure if and only if a gcc C nested function would need a trampoline for exporting as a "normal" function. C++ Lambdas without
such captures can be converted to normal function pointers, while those
with a capture structure cannot (you can pass it as a more general std::function<> object - that's more complicated, but avoids
trampolines). Attempting to write code that uses C++ lambdas instead of
gcc C nested functions, where a trampoline is actually created, will
fail in C++.



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/09/2026 21:42, fir wrote:

as im being accused on talkin not on topics
(partially it may be true but its from practical reasons, i often
do and think on more standard c sometimes im focused on deeper c)

note hovever discussing c extensions and ideas is quite regular and
natural in this group i only did possibly more of this than anybody
(or most)

for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal modularity"
(or "hipermodularty) in wider scope realizes this

i began to think on this becouse wider hipermodularity in fact im sure
is right way but yeilds to some harder decisions becouse many things are
yet not clear so maybe i think i could consider /rethink this more
narrow scope to get for some conclusion - see for example this

this kinda proves that

You have not "proven" anything of the sort. But nested or local
functions are a feature people find useful in many languages. gcc
supports them as an extension in C, and a great many languages
(including C++, Objective-C, and D, which are all "C-like" languages).

1) functions in functuions finally shows to be good idea
2) its quite close if adding it to objects as in oop
(not fully as many impelenetationsof this oop (wth this
net of pointers) is total trash i eman on this more proper
"entity" form of objects (this entity form i personally usualy name as module, but it also could be named repaired object in short object)

No, it is not.

float* f = new float; //oop trash way
float f;ÿÿ //'entity' way/right way/c way (in this way f could be named
as object imo or module )

It's clear that you have no idea what OOP means, and pretty much zero knowledge of C++. The focus here is obviously C rather than C++, but it doesn't help your argument when you dismiss C++ this way. If C were
ever to gain standardised nested functions, they would be lambdas in a
C++ style (this is already in progress as a set of proposals lead by
Jens Gustedt). Similarly, if namespaces (which is closer to what you
are describing below) are added to C, it will be following C++ syntax.
No one wants to re-invent wheels, especially when the new version is a
big step backwards.

so the example

int print(char*txt)
{

ÿ int n = printf(txt);

ÿ chars+=n;
ÿ calls++;

ÿ return n;

ÿ static intÿ calls = 0;
ÿ static intÿ chars = 0;

ÿ float average()ÿÿÿ {ÿ return float(chars)/calls;}
ÿ void printf_average() {ÿ printf("calls %d, chars%d, average chars on
call %f ", calls, chars, average()ÿ ); }
ÿ void reset() {calls =0; chars =0;}
ÿ};

That is not an "object" (and certainly not "OOP"), nor is it nested
functions in any real sense - it is a namespace where one of the
functions has its definition muddled up. Really, what you have is :

namespace print {
int calls = 0; // Inherently static in a namespace
int chars = 0;

int print(char * txt) {
int n = printf(txt);
chars += n;
calls ++;
return n;
}

float average() { return float(chars) / calls; }
...
}


Adding namespaces to C is not a bad idea, but it is complicated by how external linkage names are formed - C does not have the "name mangling"
of C++. There is a proposal to do add language support in C that also
works with the C tradition of "MyLib_" style prefixes.

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3848.pdf>

this alone maybe not opens so many questions, some may just use it
on c standard rules

main()
{
ÿprint("sdsdssfd");
ÿprint("sdsdsddsdsfd");

ÿprint. printf_average();

}

evenyually someone could ask if to add a parent function name prefix
here as obligatory

ÿprint. printf_average(); //this ?
ÿprintÿ printf_average(); //this ?
ÿprintf_average();ÿ //or this?

in my opinieon (but not decisive/final only for the consideration at the moment) probably all 3 should be allowed

Allowing all three is worse than choosing any single option, no matter
how bad that option may be.

probably in this moment

1) usability of this functions in functions is clear
2) not much language problems arise

BUT THE GENERALISATIONS of it (i mean draggging that functions into
being treated as a structure NOW MANY PROBLEMS arise (and on this maybe later)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

note i her gave two examples

1) print() but with accesible fields (of its aclls and chars printed )
and cunstions (to show it)
2) reallocalbe 2d array contained in function

few days ago i was giving example of slog() routines which is
combination of the two (it has rectangle ram buffer where you write text
into (by vsprintf) and you mat draw this slog ram buffer onto
screen (by winapi/gdi based function)


so this open a question how to sho this slog in such form of one
function


the problem is this slog has its main function and if it this function
should be used for initialisation or for printing then ??

in fact you can define it as you want but should it be somewhat fixed on language level?

i dont know i woule probably design it like this

slog(char* txt, ...)
{

// if(!buf) buf = realloc(buf, w*h);

if(!buf) resize(100, 200);


// pass to vsnprintf here

return;

// static int w = 100;
// static int h = 200;
static w =0, h=0;
static char* buf = NULL;

void resize(int _w, int _h) {w=_w;_h=h; buf = realloc(buf, w*h);}

void draw(int x, int y) { //use gdi calls here}



}

this opens some problem hobvever
1) you need to hardcode default w,h size in this function (as you dont
call init as instantiation) and/or you need to pass thru this pointer
check if its initialised

so thismay suggest its not purely theoratically good here in this form

so it needs some thinking










--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

On 16/09/2026 21:42, fir wrote:

as im being accused on talkin not on topics
(partially it may be true but its from practical reasons, i often
do and think on more standard c sometimes im focused on deeper c)


note hovever discussing c extensions and ideas is quite regular and
natural in this group i only did possibly more of this than anybody
(or most)


for exampla i remembered some people doscussed concept of functions
inside functions in c and this my concept of this "fractal modularity"
(or "hipermodularty) in wider scope realizes this

i began to think on this becouse wider hipermodularity in fact im sure
is right way but yeilds to some harder decisions becouse many things
are yet not clear so maybe i think i could consider /rethink this more
narrow scope to get for some conclusion - see for example this

this kinda proves that

You have not "proven" anything of the sort.ÿ But nested or local
functions are a feature people find useful in many languages.ÿ gcc
supports them as an extension in C, and a great many languages
(including C++, Objective-C, and D, which are all "C-like" languages).

1) functions in functuions finally shows to be good idea
2) its quite close if adding it to objects as in oop
(not fully as many impelenetationsof this oop (wth this
net of pointers) is total trash i eman on this more proper
"entity" form of objects (this entity form i personally usualy name as
module, but it also could be named repaired object in short object)

No, it is not.

float* f = new float; //oop trash way
float f;ÿÿ //'entity' way/right way/c way (in this way f could be
named as object imo or module )

It's clear that you have no idea what OOP means, and pretty much zero knowledge of C++.ÿ The focus here is obviously C rather than C++, but it doesn't help your argument when you dismiss C++ this way.ÿ If C were
ever to gain standardised nested functions, they would be lambdas in a
C++ style (this is already in progress as a set of proposals lead by
Jens Gustedt).ÿ Similarly, if namespaces (which i

it proves - but you just dont understand it


(note hovever what word prove mean - it shows some usability and some
logical consequences...

but i cant say on this with someone who do not understand it..
note i know hat i write is hard to understand to regular c user
so i maybe even except it to be understood only partially..)


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

That is not an "object" (and certainly not "OOP"), nor is it nested functions in any real sense - it is a namespace where one of the
functions has its definition muddled up.ÿ Really, what you have is :

namespace print {
ÿÿÿÿint calls = 0;ÿÿÿÿÿÿÿ // Inherently static in a namespace
ÿÿÿÿint chars = 0;

ÿÿÿÿint print(char * txt) {
ÿÿÿÿÿÿÿ int n = printf(txt);
ÿÿÿÿÿÿÿ chars += n;
ÿÿÿÿÿÿÿ calls ++;
ÿÿÿÿÿÿÿ return n;
ÿÿÿÿ}

ÿÿÿÿfloat average() { return float(chars) / calls; }
ÿÿÿÿ...
}

ye thats right.. its nice you understand it

but now:

I. it is an object but as i said i consider this as a "narrowed"
piece of more general exctension where thsi function is an "object"
(bot not quite c++ trash object but close though repaired) ..in
this narrow sense it yet not be may seen it is

see the numerous differences
I.


thise calls and chars are static variables in my versions,
and thise inner functions (maybe named they inner not to confuse with
GNU nested) have acces to it

II.

im not exactly used to use c++ namespaces so i dont know how those
differences (cals and chars are static inner functions has acces to it)
make differences in usage - what you can do or cant do with this inner functions scheme hera and what you can do and cant do with namespace
scheme

III.
there more theorethical subt;lities here..like for example thise third
kind of scope i defined here (down-the-branch scope)




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

ÿÿprint. printf_average(); //this ?
ÿÿprintÿ printf_average(); //this ?
ÿÿprintf_average();ÿ //or this?

in my opinieon (but not decisive/final only for the consideration at
the moment) probably all 3 should be allowed

Allowing all three is worse than choosing any single option, no matter
how bad that option may be.

not really

c tradition i guess would be the third - no prefixes

but 1&|2 (1 and/or 2 ..i men 1 o2 or both) is needed
- this allows you to use many short names for inner functions and do not
make conflict if they are in scope just use prefix - but as i said such decision on specified syntax must be dalayed )

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

note i her gave two examples

1) print() but with accesible fields (of its aclls and chars printed )
and cunstions (to show it)
2) reallocalbe 2d array contained in function

few days ago i was giving example of slog() routines which is
combination of the two (it has rectangle ram buffer where you write text into (by vsprintf) and you mat draw this slog ram buffer onto
screen (by winapi/gdi based function)

so this open a question how to sho this slog in such form of one
function

the problem is this slog has its main function and if it this function should be used for initialisation or for printing then ??

in fact you can define it as you want but should it be somewhat fixed on language level?

i dont know i woule probably design it like this

slog(char* txt, ...)
{

//ÿ if(!buf) buf = realloc(buf, w*h);

ÿ if(!buf) resize(100, 200);

ÿ // pass to vsnprintf here

ÿ return;

//ÿ static int w = 100;
//ÿ static int h = 200;
ÿ static w =0, h=0;
ÿ static char* buf = NULL;

ÿ void resize(int _w, int _h) {w=_w;_h=h; buf = realloc(buf, w*h);}

ÿ void draw(int x, int y) { //use gdi calls here}

}

this opens some problem hobvever
1) you need to hardcode default w,h size in this function (as you dont
call init as instantiation) and/or you need to pass thru this pointer
check if its initialised

so thismay suggest its not purely theoratically good here in this form

so it needs some thinking

this is also not bad hovever for c user (i personally use such

kind of "init key" pointers or how to name it in my c codes)


more runtime proper form seem to be

slog(int w, int h)
{

resize(w,h);

return;

static w =0, h=0;
static char* buf = NULL;

void resize(int _w, int _h) {w=_w;_h=h; buf = realloc(buf, w*h);}

void print(char* txt,..) {
// pass args to vsnprintf here to write in buf }

void draw(int x, int y) { //use gdi calls here to draw buf onscreen}



}

its runtime proper imo, it also has some logical advantege maybe
(becouse if those sons (inner fields) and doughters (inner functions)
have down the branch scope it seems is more type safety 'logically'

(the previous version if also has down the branch scope, im nnot sure
that would work, becouse it seem that it was opening many scopes in
each points of its usege (?) im not sure would need to rethink that)


PROBLEM IS hobever this seem more verbose as you need 2 calls to make
it wprk

slog(20,20);
print("sdsd");

and i think this is downgrade i should take seriously maybe




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

David Brown pisze:

ÿÿprint. printf_average(); //this ?
ÿÿprintÿ printf_average(); //this ?
ÿÿprintf_average();ÿ //or this?

in my opinieon (but not decisive/final only for the consideration at
the moment) probably all 3 should be allowed

Allowing all three is worse than choosing any single option, no matter
how bad that option may be.

not really

c tradition i guess would be the third - no prefixes

but 1&|2ÿ (1 and/or 2 ..i men 1 o2 or both) is needed
- this allows you to use many short names for inner functions and do not make conflict if they are in scope just use prefix - but as i said such decision on specified syntax must be dalayed )

note btw in one pice of post yu give example of namespaces and then
criticoze thsi above when namespaces arair give you such option
to use prefix or not

print::print_average()
print_average()

afair (but not sure if right) it needs hovevever adding use namespce
print which is downgrad as here print brings its own namespace at place


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 17/09/2026 12:58, fir wrote:

David Brown pisze:

That is not an "object" (and certainly not "OOP"), nor is it nested
functions in any real sense - it is a namespace where one of the
functions has its definition muddled up.ÿ Really, what you have is :

namespace print {
ÿÿÿÿÿint calls = 0;ÿÿÿÿÿÿÿ // Inherently static in a namespace
ÿÿÿÿÿint chars = 0;

ÿÿÿÿÿint print(char * txt) {
ÿÿÿÿÿÿÿÿ int n = printf(txt);
ÿÿÿÿÿÿÿÿ chars += n;
ÿÿÿÿÿÿÿÿ calls ++;
ÿÿÿÿÿÿÿÿ return n;
ÿÿÿÿÿ}

ÿÿÿÿÿfloat average() { return float(chars) / calls; }
ÿÿÿÿÿ...
}

ye thats right.. its nice you understand it

but now:

I. it is an object but as i said i consider this as a "narrowed"
piece of more general exctension where thsi function is an "object"
(bot not quite c++ trash object but close though repaired) ..in
this narrow sense it yet not be may seen it is

An "object" has to be re-usable - you have to be able to have multiple independent instances of the object type. If all your data fields are "static", you can only have one of them - and you have a namespace,
rather than an object type.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

so the example


int print(char*txt)
{

ÿÿ int n = printf(txt);

ÿÿ chars+=n;
ÿÿ calls++;

ÿÿ return n;

ÿÿ static intÿ calls = 0;
ÿÿ static intÿ chars = 0;

ÿÿ float average()ÿÿÿ {ÿ return float(chars)/calls;}
ÿÿ void printf_average() {ÿ printf("calls %d, chars%d, average chars
on call %f ", calls, chars, average()ÿ ); }
ÿÿ void reset() {calls =0; chars =0;}
ÿÿ};

That is not an "object" (and certainly not "OOP"), nor is it nested functions in any real sense - it is a namespace where one of the
functions has its definition muddled up.

note hovevr how far this is form object (i assume you understand how to
read the constructions i showed as it seem fortunatelly you do)


slog(int w, int h)
{

resize(w,h);

return;

static w =0, h=0;
static char* buf = NULL;

void resize(int _w, int _h) {w=_w;_h=h; buf = realloc(buf, w*h);}

void print(char* txt,..) {//pass args to vsnprintf here to write in buf }

void draw(int x, int y) { //use gdi calls here to draw buf onscreen}



}

say you wnt to make aray of this

main()
{
slog [20]; //nev syntax as slog(ibt w, int h) is 'function'

for(int i=0; i<20; i++)
slog(rand()%30, rand()%30);

//same as
// slog(27, 8);
// slog(17, 18);
// slog(2, 23);
// slog(27, 4);
// slog(12,23);
// slog(8, 18);
//...

//but inexed (this one probbaly would need alisases coz if use same
name im not sure thios probably should call the seme function twice thus yeilding to resizing not making one (?)

above is also an option to call this for loop interbally like

slog[20](rand()%30, rand()%30); //though it need soem more syntax to distinguish calling on object 20


//i dont kniow maybe something
// slog[0..19](rand()%30, rand()%30);

}

array would hold {int w,h; char* buf;}
and calls would adress that


like

slog[i] print("sdasdsd")

slog[i].resize(10,20)


imo its not much far from objects imo -static fields simply become
object fields






--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

On 17/09/2026 12:58, fir wrote:

David Brown pisze:

That is not an "object" (and certainly not "OOP"), nor is it nested
functions in any real sense - it is a namespace where one of the
functions has its definition muddled up.ÿ Really, what you have is :

namespace print {
ÿÿÿÿÿint calls = 0;ÿÿÿÿÿÿÿ // Inherently static in a namespace
ÿÿÿÿÿint chars = 0;

ÿÿÿÿÿint print(char * txt) {
ÿÿÿÿÿÿÿÿ int n = printf(txt);
ÿÿÿÿÿÿÿÿ chars += n;
ÿÿÿÿÿÿÿÿ calls ++;
ÿÿÿÿÿÿÿÿ return n;
ÿÿÿÿÿ}

ÿÿÿÿÿfloat average() { return float(chars) / calls; }
ÿÿÿÿÿ...
}

ye thats right.. its nice you understand it

but now:

I. it is an object but as i said i consider this as a "narrowed"
piece of more general exctension where thsi function is an "object"
(bot not quite c++ trash object but close though repaired) ..in
this narrow sense it yet not be may seen it is

An "object" has to be re-usable - you have to be able to have multiple independent instances of the object type.ÿ If all your data fields are "static", you can only have one of them - and you have a namespace,
rather than an object type.

thets rhigh bot it is nothing across the fact that you can instantiate it

void foo (double x)
{
static double d ;

d =sin(x);
return;
}


you need only chose a syntax here

there is a question if to mix such instantation with calling

foo(0.1) a; //or foo a(0.1);
foo(0.2) b;
foo(0.3) c;
foo(0.0)[10];

or treat it as separate


foo a,b,c, tab[10];


more old c way is treat separate (but as to deep c im not sure)

NOTE this slight additions make it 'object' in c++ like way (but
better) but more upgraded form is hipermodule (and this hipermodule if
more made by this idea of wider fractal unification of things in c)






--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

or treat it as separate

foo a,b,c, tab[10];

here above this foo works like type, like object, like function , like
module (as definition as a piece of code/code unit) ad operators and it
would also work liek fundamental (builtin-type)

and as its seems not much is needed



as implementtaion i think the impelementation of foo(int x, iny y, int
z) rather should no pass anu additional argument but more like hidden
static field with reference to its static data block in ram (optimised
away probbaly in some cases)


passing pointer to all method my maybe illustrate typical c++
stupidity as if you got 100 methods you dont need 100 passes
but reuse the hidded static field with pointer reference

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

or treat it as separate

foo a,b,c, tab[10];

this separation (among instantation and first call) is separate
probem

for example if foo needs to be dynamically allocated if i
instantiate it it is not for use down the stack /down the branch

but from other point of view its maybe nice?

more complex dillemas here as there is more options like


foo()
{
printf("asdsad");

static x ;
}

main(){
foo; //should it call printf?
}

maybe not but im not shure

this foo would work like instantation and namespacing.. here
question maybe only namaspacing could be nneded? like adding big
windows module... but maybe not becouse some functions would need static fields also this instantation may be possibly deffered down the stack i
guess




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 17 Sep 2026 09:49:09 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of
functions inside functions in c and this my concept of this
"fractal modularity" (or "hipermodularty) in wider scope realizes
this

It?s called ?nested functions?. The GNU C compiler already has
this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk,
which is usually created on the stack. This requires an executable
stack.

interesting, i didnt knew that

but it seems it doesnt work as it should

in cas im talking about those inner functions

1) has visibility as it was not inner (like normal)

Nothing that is defined local to a scope is supposed to be visible
outside it. That?s the whole point of ?local scope?.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro pisze:

On Thu, 17 Sep 2026 09:49:09 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of
functions inside functions in c and this my concept of this
"fractal modularity" (or "hipermodularty) in wider scope realizes
this

It?s called ?nested functions?. The GNU C compiler already has
this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk,
which is usually created on the stack. This requires an executable
stack.

interesting, i didnt knew that

but it seems it doesnt work as it should

in cas im talking about those inner functions

1) has visibility as it was not inner (like normal)

Nothing that is defined local to a scope is supposed to be visible
outside it. That?s the whole point of ?local scope?.

here the doughters are wisible not inside mommy but aside/beside momy
(and probably down the branch)



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

Lawrence D?Oliveiro pisze:

On Thu, 17 Sep 2026 09:49:09 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

On Wed, 16 Sep 2026 21:42:54 +0200, fir wrote:

for exampla i remembered some people doscussed concept of
functions inside functions in c and this my concept of this
"fractal modularity" (or "hipermodularty) in wider scope realizes
this

It?s called ?nested functions?. The GNU C compiler already has
this.

It has some implications for functions as first-class objects: the
address of an inner function has to be implemented via a thunk,
which is usually created on the stack. This requires an executable
stack.

interesting, i didnt knew that

but it seems it doesnt work as it should

in cas im talking about those inner functions

1) has visibility as it was not inner (like normal)

Nothing that is defined local to a scope is supposed to be visible
outside it. That?s the whole point of ?local scope?.

here the doughters are wisible not inside mommy but aside/beside momy
(and probably down the branch)

so as user david brown rightfully noticed it work like namespaces


mom(){
{

alice() {}
brenda{} {}

}

main()
{
mom();

alice(); //alice and brenda avaliable only becouse mom is called
brenda();

branch_down()
}


branch_down()
{

//here mom alice and vbrenda also avaliable

//this maybe i must yet rethink but it seems so
}

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

foo a,b,c, tab[10];

so there are two options

main()
{
foo;
foo();
}
taking og C traditions it could be taken that foo wrk like structure and
foo() like function so in such case

int foo(char* txt)
{

return print(txt);;

static x,y,z;

f() {}

}

foo; not calls code and return x,y,z
where foo() calls code and returns int

this is one possible scenario and its quite traditional but im not sure
if right (but for now it sims bigger consideration)

most traditional aliasing would be


foo a; // instantiate foo with name a

foo a("asas"); //same but also call




though there are some open questions for example if you instantiate array


foo(int w,int h)
{

static int width =w;
static int height=h;
buf[height][width];

return;

}


then this is not exactly code calling probably even if buf is made on
the heap (it also may be on stack) (maybe there should be keywords avaliable


foo(int w,int h)
{

stack/heap/static int width =w;
stack/heap/static int height=h;
stack/heap/static buf[height][width];

return;

}

so i think probably it should belong to this no call category somewhat
(not clear if those arguments in header should be usuing different conventionion etc)

overally it seems that even static data should be allocated in ram
on first call


main()
{
//....
foo(); //foo uses big static array so alloc it late (?)
//though as system knows all static rams need to be alocated ahead
it may shiow dialog of warning before allocating it if there is no ram
(unlike with heap)


}




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)