bart pisze:

On 06/09/2026 14:25, fir wrote:

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], >>>>>>>>> name)

(It's beyond me why one would prefer macros to a function here.
But your basic idea to extract the invariant is of course sensible.) >>>>>> There isn't enough info to see how to write an effective function. >>>>>>

But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In
that case, the sdodge calls will not be so different from the
original slog calls.

All we can do is suggest different ideas and ways to arrange such
code, and maybe the OP will see something he feels is a good fit
for his needs.ÿ As you say, we are missing a lot of information
about the rest of the code - we don't know what data is "global" or >>>>> local, when any of these parts might be re-used, how likely it is
that the details or boundary points will be changed, and countless
other details.

In general, I am very sceptical about using macros for this kind of >>>>> thing.ÿ It is correct that they let you implicitly pass local data
into the macro in a way that functions do not - but that can make
the structure a lot harder to follow, and becomes fragile for
changes. So while it is definitely something that can occasionally
be helpful, I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is
gcc nested functions - these can capture such local variables in a
safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not
standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist
will touch c it would be a heavy disaster (they touched it already
too much)

what i strongly need is those long t = 'somethin'; here to this tags
could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is rarely
bigger than 32 bits, so it can only have 'ABCD' (and C itself may
only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it
yields a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is
not going to be of immediate help.

I suggest, if you really need those features soon (this is including
the new 'match' statements), that you write a special preprocessor
which takes programs written in this enhanced C, and generates
standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare it
to another ''

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
ÿÿ sjhbshj,
ÿÿ ala,
ÿÿ bala,
ÿÿ something
};

There is no limit on length, and variables containing such enums don't
need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

i know it exist but the definitions and managment of them etc (where tu
put etc, all code jumping releted, yet some superior type over tags etc
is so no needed and annoying its simple a trash (thiose definition is
trash totaly not standable) - defining structures llike

struct sjhbshj {};
struct ala {};
struct bala {};
struct something {};


in fact is better (less this annoyances) but still big annoyances stand
so just typeles adhoc tags 'sjhbshj' 'ala' 'bala' 'something' is the
only way here..its absolute basic type that c lacks - and can be
mimicked by those

int x= 'dfgh';

quite well but its too short

(i also noted some implementation of this can be faster inplementing
this tags as a numbers under the hood so unsigned or short value passed
will sufice for all such tags in whole big project, allowing to have it
also very long names with no overhead (i repeat this as i talked on this
mant times but i know some may eventually not know what im talkin about
as it was back ten and not everyone had read this and remember what im
talkin about again probably)





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

fir pisze:

bart pisze:

On 06/09/2026 14:25, fir wrote:

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...", being[k], >>>>>>>>>> name)

(It's beyond me why one would prefer macros to a function here. >>>>>>>> But your basic idea to extract the invariant is of course
sensible.)

There isn't enough info to see how to write an effective function. >>>>>>>
But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In >>>>>>> that case, the sdodge calls will not be so different from the
original slog calls.

All we can do is suggest different ideas and ways to arrange such >>>>>> code, and maybe the OP will see something he feels is a good fit
for his needs.ÿ As you say, we are missing a lot of information
about the rest of the code - we don't know what data is "global"
or local, when any of these parts might be re-used, how likely it >>>>>> is that the details or boundary points will be changed, and
countless other details.

In general, I am very sceptical about using macros for this kind
of thing.ÿ It is correct that they let you implicitly pass local
data into the macro in a way that functions do not - but that can >>>>>> make the structure a lot harder to follow, and becomes fragile for >>>>>> changes. So while it is definitely something that can occasionally >>>>>> be helpful, I think it is rarely the best solution.

If the OP is happy with compiler extensions, a possibility here is >>>>>> gcc nested functions - these can capture such local variables in a >>>>>> safer and more structured manner, keeping the details within the
function itself. (Or he could use C++ and lambdas for a similar
effect.ÿ There are proposals to add lambdas to C, but they are not >>>>>> standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist
will touch c it would be a heavy disaster (they touched it already
too much)

what i strongly need is those long t = 'somethin'; here to this
tags could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints)

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit
types as they were not that useful to me (only for implementing 128-
types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is
rarely bigger than 32 bits, so it can only have 'ABCD' (and C itself
may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it
yields a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting? Are
these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there is
not going to be of immediate help.

I suggest, if you really need those features soon (this is including
the new 'match' statements), that you write a special preprocessor
which takes programs written in this enhanced C, and generates
standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare
it to another ''

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
ÿÿÿ sjhbshj,
ÿÿÿ ala,
ÿÿÿ bala,
ÿÿÿ something
};

There is no limit on length, and variables containing such enums don't
need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

i know it exist but the definitions and managment of them etc (where tu
put etc, all code jumping releted, yet some superior type over tags etc
is so no needed and annoying its simple a trash (thiose definition is
trash totaly not standable) - defining structures llike

structÿ sjhbshj {};
structÿ ala {};
structÿ bala {};
structÿ something {};

in fact is better (less this annoyances) but still big annoyances stand
so just typeles adhoc tags 'sjhbshj' 'ala' 'bala' 'something' is the
only way here..its absolute basic type that c lacks - and can be
mimicked by those

int x= 'dfgh';

quite well but its too short

(i also noted some implementation of this can be faster inplementing
this tags as a numbers under the hood so unsigned or short value passed
will sufice for all such tags in whole big project, allowing to have it
also very long names with no overhead (i repeat this as i talked on this mant times but i know some may eventually not know what im talkin about
as it was back ten and not everyone had read this and remember what im talkin about again probably)

i mention this structures as i once noticed this kind of tags can cally
a value for zero cost

i mean you can do something like that

print('red', "ala");
print('blue', "ala");
print('fancy', "ala");

and id 'red' 'blue' 'fancy' are implemented as a pointers
yu may add any data to it as like 'red' 'blue' 'fancy' are structure
each one may have different fields

like 'fancy' {unsigned color = 0xcc0000; char* name = "lucida console";
int size = 25;}

so this is additional big advantage


internally code just use

ud(tag=='fancy') print_text_extended('fancy'.color, 'fancy'.name, 'fancy'.size, text) ;

//a bit not sure if this should be tag.name or 'fancy'.name, but
probably teh latter

so possibly good implementation of this tags (adhoc enums) is pointer
but this is deeper functionality below the basic also extremally needed one


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

fir pisze:

fir pisze:

bart pisze:

On 06/09/2026 14:25, fir wrote:

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...",
being[k], name)

(It's beyond me why one would prefer macros to a function here. >>>>>>>>> But your basic idea to extract the invariant is of course
sensible.)

There isn't enough info to see how to write an effective function. >>>>>>>>
But if 'being[]' and 'name' are locals (or 'k' if 'being' is
global), then the function will need those extra parameters. In >>>>>>>> that case, the sdodge calls will not be so different from the >>>>>>>> original slog calls.

All we can do is suggest different ideas and ways to arrange such >>>>>>> code, and maybe the OP will see something he feels is a good fit >>>>>>> for his needs.ÿ As you say, we are missing a lot of information >>>>>>> about the rest of the code - we don't know what data is "global" >>>>>>> or local, when any of these parts might be re-used, how likely it >>>>>>> is that the details or boundary points will be changed, and
countless other details.

In general, I am very sceptical about using macros for this kind >>>>>>> of thing.ÿ It is correct that they let you implicitly pass local >>>>>>> data into the macro in a way that functions do not - but that can >>>>>>> make the structure a lot harder to follow, and becomes fragile
for changes. So while it is definitely something that can
occasionally be helpful, I think it is rarely the best solution. >>>>>>>
If the OP is happy with compiler extensions, a possibility here >>>>>>> is gcc nested functions - these can capture such local variables >>>>>>> in a safer and more structured manner, keeping the details within >>>>>>> the function itself. (Or he could use C++ and lambdas for a
similar effect.ÿ There are proposals to add lambdas to C, but
they are not standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist >>>>>> will touch c it would be a heavy disaster (they touched it already >>>>>> too much)

what i strongly need is those long t = 'somethin'; here to this
tags could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints) >>>>>

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit >>>>> types as they were not that useful to me (only for implementing
128- types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is
rarely bigger than 32 bits, so it can only have 'ABCD' (and C
itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it
yields a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting?
Are these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there
is not going to be of immediate help.

I suggest, if you really need those features soon (this is
including the new 'match' statements), that you write a special
preprocessor which takes programs written in this enhanced C, and
generates standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare
it to another ''

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
ÿÿÿ sjhbshj,
ÿÿÿ ala,
ÿÿÿ bala,
ÿÿÿ something
};

There is no limit on length, and variables containing such enums
don't need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

i know it exist but the definitions and managment of them etc (where
tu put etc, all code jumping releted, yet some superior type over tags
etc is so no needed and annoying its simple a trash (thiose definition
is trash totaly not standable) - defining structures llike

structÿ sjhbshj {};
structÿ ala {};
structÿ bala {};
structÿ something {};


in fact is better (less this annoyances) but still big annoyances stand
so just typeles adhoc tags 'sjhbshj' 'ala' 'bala' 'something' is the
only way here..its absolute basic type that c lacks - and can be
mimicked by those

int x= 'dfgh';

quite well but its too short

(i also noted some implementation of this can be faster inplementing
this tags as a numbers under the hood so unsigned or short value passed
will sufice for all such tags in whole big project, allowing to have
it also very long names with no overhead (i repeat this as i talked on
this mant times but i know some may eventually not know what im talkin
about as it was back ten and not everyone had read this and remember
what im talkin about again probably)

i mention this structures as i once noticed this kind of tags can cally
a value for zero cost

i mean you can do something like that

print('red', "ala");
print('blue', "ala");
print('fancy', "ala");

and id 'red' 'blue' 'fancy' are implemented as a pointers
yu may add any data to it as like 'red' 'blue' 'fancy' are structure
each one may have different fields

like 'fancy' {unsigned color = 0xcc0000; char* name = "lucida console";
int size = 25;}

so this is additional big advantage

internally code just use

ud(tag=='fancy') print_text_extended('fancy'.color, 'fancy'.name, 'fancy'.size, text) ;

//a bit not sure if this should be tag.name or 'fancy'.name,ÿ but
probably teh latter

so possibly good implementation of this tags (adhoc enums) is pointer
but this is deeper functionality below the basic also extremally needed one

it may even carry a functions..what more it probbaly dont need to be
passed as pointer..coz if say 'blue' "carry" a function foo_blue()

then in this if in its client function you may call

if(tag=='blue')
{
'blue'.foo_blue(2,344,44); and thsi is copile time known so no pasing
here if im not wrong
}

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

fir pisze:

fir pisze:

fir pisze:

bart pisze:

On 06/09/2026 14:25, fir wrote:

bart pisze:

On 06/09/2026 11:12, fir wrote:

David Brown pisze:

On 06/09/2026 01:06, bart wrote:

On 05/09/2026 18:03, Janis Papanagnou wrote:

On 2026-09-05 16:16, David Brown wrote:

On 05/09/2026 14:10, bart wrote:

ÿÿ #define sdodge(x) slog("%s" x "dodged attack...",
being[k], name)

(It's beyond me why one would prefer macros to a function here. >>>>>>>>>> But your basic idea to extract the invariant is of course >>>>>>>>>> sensible.)

There isn't enough info to see how to write an effective function. >>>>>>>>>
But if 'being[]' and 'name' are locals (or 'k' if 'being' is >>>>>>>>> global), then the function will need those extra parameters. In >>>>>>>>> that case, the sdodge calls will not be so different from the >>>>>>>>> original slog calls.

All we can do is suggest different ideas and ways to arrange
such code, and maybe the OP will see something he feels is a
good fit for his needs.ÿ As you say, we are missing a lot of
information about the rest of the code - we don't know what data >>>>>>>> is "global" or local, when any of these parts might be re-used, >>>>>>>> how likely it is that the details or boundary points will be
changed, and countless other details.

In general, I am very sceptical about using macros for this kind >>>>>>>> of thing.ÿ It is correct that they let you implicitly pass local >>>>>>>> data into the macro in a way that functions do not - but that >>>>>>>> can make the structure a lot harder to follow, and becomes
fragile for changes. So while it is definitely something that >>>>>>>> can occasionally be helpful, I think it is rarely the best
solution.

If the OP is happy with compiler extensions, a possibility here >>>>>>>> is gcc nested functions - these can capture such local variables >>>>>>>> in a safer and more structured manner, keeping the details
within the function itself. (Or he could use C++ and lambdas for >>>>>>>> a similar effect.ÿ There are proposals to add lambdas to C, but >>>>>>>> they are not standardised yet.)

lol, adding almbdas to c that would be a trash... if the populist >>>>>>> will touch c it would be a heavy disaster (they touched it
already too much)

what i strongly need is those long t = 'somethin'; here to this >>>>>>> tags could work up to 8 lengthÿ (or 16 if some cpu has 128 bit ints) >>>>>>

I used to have both of those (in my language), so I could write
'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped
128-bit types as they were not that useful to me (only for
implementing 128- types within the compiler!).

I still have 'ABCDEFGH'.

C however limits such constants to the size of 'int', which is
rarely bigger than 32 bits, so it can only have 'ABCD' (and C
itself may only guarantee 'A').

(My C compiler is different, in allowing 'ABCDEFGH'; I think it
yields a 64-bit type in this case.)


So, given the current limitations, then what are you suggesting?
Are these just ideas for C extensions, or for a new language?

If you need such features now, then putting these ideas out there >>>>>> is not going to be of immediate help.

I suggest, if you really need those features soon (this is
including the new 'match' statements), that you write a special
preprocessor which takes programs written in this enhanced C, and >>>>>> generates standard C.

So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare >>>>> it to another ''

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
ÿÿÿ sjhbshj,
ÿÿÿ ala,
ÿÿÿ bala,
ÿÿÿ something
};

There is no limit on length, and variables containing such enums
don't need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

i know it exist but the definitions and managment of them etc (where
tu put etc, all code jumping releted, yet some superior type over
tags etc is so no needed and annoying its simple a trash (thiose
definition is trash totaly not standable) - defining structures llike

structÿ sjhbshj {};
structÿ ala {};
structÿ bala {};
structÿ something {};


in fact is better (less this annoyances) but still big annoyances stand
so just typeles adhoc tags 'sjhbshj' 'ala' 'bala' 'something' is the
only way here..its absolute basic type that c lacks - and can be
mimicked by those

int x= 'dfgh';

quite well but its too short

(i also noted some implementation of this can be faster inplementing
this tags as a numbers under the hood so unsigned or short value passed
will sufice for all such tags in whole big project, allowing to have
it also very long names with no overhead (i repeat this as i talked
on this mant times but i know some may eventually not know what im
talkin about as it was back ten and not everyone had read this and
remember what im talkin about again probably)

i mention this structures as i once noticed this kind of tags can
cally a value for zero cost

i mean you can do something like that

print('red', "ala");
print('blue', "ala");
print('fancy', "ala");

and id 'red' 'blue' 'fancy' are implemented as a pointers
yu may add any data to it as like 'red' 'blue' 'fancy' are structure
each one may have different fields

like 'fancy' {unsigned color = 0xcc0000; char* name = "lucida
console"; int size = 25;}

so this is additional big advantage


internally code just use

ud(tag=='fancy') print_text_extended('fancy'.color, 'fancy'.name,
'fancy'.size, text) ;

//a bit not sure if this should be tag.name or 'fancy'.name,ÿ but
probably teh latter

so possibly good implementation of this tags (adhoc enums) is pointer
but this is deeper functionality below the basic also extremally
needed one

it may even carry a functions..what more it probbaly dont need to be
passed as pointer..coz if say 'blue' "carry" a function foo_blue()

then in this if in its client function you may call

if(tag=='blue')
{
ÿ'blue'.foo_blue(2,344,44); and thsi is copile time known so no pasing
here if im not wrong
}

it also suggest th option to write this tags not lik 'blue' but blue

foo(blue,10,10); //blue is not defined its adhoc
foo(red,56,66);

its worth considering though it has some disadwantages - it is the same
name space as identifiers (which may be good but also you need to take
care not to repeat ones)..also in not sure if this would loose type
system etc (but maybe not too much it would need to be rethinked eventually)//eventually maybe some could just use some naming convention
like @blue for tags/adhoc enums

foo(@blue,10,10);
foo(@red,56,66);

im not sure though (not saying definitelly)



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

On Sun, 6 Sep 2026 16:42:55 +0100, bart wrote:

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
sjhbshj,
ala,
bala,
something
};

There is no limit on length, and variables containing such enums
don't need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

A bit limiting in capabilities, compared to, say, enums in C++, Java
or Python.

Python?s enums are particularly powerful. They?re not some separate
category of type built into the language, instead, they?re just
classes that inherit from a base class provided in a standard library
module. So you can use multiple inheritance and subclassing with them,
which you can?t in those other languages.

And that standard library module doesn?t actually do anything you
can?t do in your own Python code.

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

On 9/19/2026 9:33 AM, Lawrence D?Oliveiro wrote:

On Sun, 6 Sep 2026 16:42:55 +0100, bart wrote:

Such enums already exist, but with some restrictions: they must be a
valid C identifier, so no embedded spaces for example:

enum {
sjhbshj,
ala,
bala,
something
};

There is no limit on length, and variables containing such enums
don't need to be 64 or even 32 bits; 8 bits will usually do.

But you also need to list them in advance.

A bit limiting in capabilities, compared to, say, enums in C++, Java
or Python.

Python?s enums are particularly powerful. They?re not some separate
category of type built into the language, instead, they?re just
classes that inherit from a base class provided in a standard library
module. So you can use multiple inheritance and subclassing with them,
which you can?t in those other languages.

And that standard library module doesn?t actually do anything you
can?t do in your own Python code.

And the advantages are what, exactly? Why do you leave this off like
a cliffhanger?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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