enum sets

[Thiago Adams]

I am wondering how useful would be to have enum sets.

Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.

But at same type you can store at same object monospaced_font_type or
font_type.

enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};

This could be arranged in any way.

[Keith Thompson]

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

If I understand you correctly, enum monospaced_font_type is a *subtype*
of enum font_type.

Ada has something very similar to this:

type Font_Type is (CASCADIA_FONT, ARIAL_FONT);
subtype monospaced_font_type is Font_type range CASCADIA_FONT .. CASCADIA_FONT;

An Ada subtype is a type with an optionally added *constraint*,
which can be checked at runtime. But it's hard to see how you'd
add this to C.

Given your type definition, how would this behave?

void func(enum monospaced_font_type);
enum font_type font = ARIAL_FONT;
func(font);

(The Ada equivalent would raise a run-time exception.)

[Keith Thompson]

Keith Thompson <Keith.S.Thompson+***@gmail.com> writes:
[...]

Post by Keith Thompson
type Font_Type is (CASCADIA_FONT, ARIAL_FONT);
subtype monospaced_font_type is Font_type range CASCADIA_FONT .. CASCADIA_FONT;

[...]

Please disregard the inconsistent use of upper and lower case. Ada,
unlike C, has case-insensitive identifiers and keywords, but here I was
just being sloppy.

[Kaz Kylheku]

Post by Keith Thompson

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

If I understand you correctly, enum monospaced_font_type is a *subtype*
of enum font_type.
type Font_Type is (CASCADIA_FONT, ARIAL_FONT);
subtype monospaced_font_type is Font_type range CASCADIA_FONT .. CASCADIA_FONT;
An Ada subtype is a type with an optionally added *constraint*,
which can be checked at runtime. But it's hard to see how you'd
add this to C.
Given your type definition, how would this behave?
void func(enum monospaced_font_type);
enum font_type font = ARIAL_FONT;
func(font);

If enums are to be "safe", the only treatment that makes sense is
a constraint violation (overridable with a cast).

The reverse conversion would not violate a constraint.

Run-time type information in enumeration tags seems like a wrong
stacking of abstractions. Enumerations are something with the help of
which you can implement dynamic typing in a run-time written in C;
you really just want them to be "dumb integers", with some compile-time
checks that catch bugs more often than they don't.

[Thiago Adams]

Post by Keith Thompson

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

If I understand you correctly, enum monospaced_font_type is a *subtype*
of enum font_type.
type Font_Type is (CASCADIA_FONT, ARIAL_FONT);
subtype monospaced_font_type is Font_type range CASCADIA_FONT .. CASCADIA_FONT;
An Ada subtype is a type with an optionally added *constraint*,
which can be checked at runtime. But it's hard to see how you'd
add this to C.
Given your type definition, how would this behave?
void func(enum monospaced_font_type);
enum font_type font = ARIAL_FONT;
func(font);
(The Ada equivalent would raise a run-time exception.)

Warning because not all font_type are monospaced_font_type.

void func(enum monospaced_font_type);

enum font_type font = ARIAL_FONT;

func(font);

(But all monospaced_font_type are also font_type.)

[David Brown]

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
    enum monospaced_font_type
    {
        CASCADIA_FONT,
    },
    ARIAL_FONT
};
This could be arranged in any way.

I think this could have some use-cases, but I suspect that often you
would want to have separate enumerations defined first, then combine
them with a sum type (aka variant, tagged union, discriminated type, etc.).


enum monospaced_font_type {
cascadia
};

enum proportional_font_type {
arial
};

typedef struct {
enum { is_monospaced_font_type, is_proportional_font_type } tag;
union {
enum monospaced_font_type mf;
enum proportional_font_type pf;
}
} font_type;


This also makes it more efficient for a function to determine which
sub-enum type a given font is. Unfortunately, C does not have good
support or syntax for sum types - it all has to be handled manually and
with either extra wrapping or no type safety. C++ does a bit better,
with enum classes and std::variant<>, but these are later additions to
the language and much less elegant than the sum types and pattern
matching found in a wide range of other languages.

One possible source of inspiration for adding features to a C-like
language is Cyclone, which was an attempt at a safer and better C.
Given that it is 20 years old and I only read about it recently, I guess
it never took off. But it could give you ideas.

<http://cyclone.thelanguage.org/wiki/Tagged%20Unions/>

[Thiago Adams]

Post by David Brown

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
     enum monospaced_font_type
     {
         CASCADIA_FONT,
     },
     ARIAL_FONT
};
This could be arranged in any way.

I think this could have some use-cases, but I suspect that often you
would want to have separate enumerations defined first, then combine
them with a sum type (aka variant, tagged union, discriminated type, etc.).
enum monospaced_font_type {
    cascadia
};
enum proportional_font_type {
    arial
};
typedef struct {
    enum { is_monospaced_font_type, is_proportional_font_type } tag;
    union {
        enum monospaced_font_type mf;
        enum proportional_font_type pf;
    }
} font_type;

One of my motivations was that I have a big enum and sometimes I need to
check in switch cases all values of some type.

For instance, let's say

enum E {A, B, C, D /*until Z*/};

And I need to check a subset for instance A, B

To have a warning if I miss some item I need to include all cases.

void f(enum E e)
{
switch(e)
{
case A:
case B:
break;

case C:
//..Z
break;
}
}
//warning you missing D case.


The problem this is not practical when the number of items is too big.
Using default:break; makes it practical but then the warning disappears.


With this enum set idea the code would be

enum E {
enum Subset {A, B}
,
C,
D /*until Z*/
};

void f(enum Subset e)
{
switch(e)
{
case A:
break;
} //warning you miss case B
}

[Thiago Adams]

Post by Thiago Adams

Post by David Brown

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you
need to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
     enum monospaced_font_type
     {
         CASCADIA_FONT,
     },
     ARIAL_FONT
};
This could be arranged in any way.

I think this could have some use-cases, but I suspect that often you
would want to have separate enumerations defined first, then combine
them with a sum type (aka variant, tagged union, discriminated type, etc.).
enum monospaced_font_type {
     cascadia
};
enum proportional_font_type {
     arial
};
typedef struct {
     enum { is_monospaced_font_type, is_proportional_font_type } tag;
     union {
         enum monospaced_font_type mf;
         enum proportional_font_type pf;
     }
} font_type;

One of my motivations was that I have a big enum and sometimes I need to
check in switch cases all values of some type.
For instance, let's say
enum E {A, B, C, D /*until Z*/};
And I need to check a subset  for instance  A, B
To have a warning if I miss some item I need to include all cases.
void f(enum E e)
{
   switch(e)
   {
     break;
     //..Z
     break;
   }
}
//warning you missing D case.
The  problem this is not practical when  the number of items is too big.
Using default:break; makes it practical but then the warning disappears.
With this enum set idea the code would be
enum E {
   enum Subset {A, B}
   ,
   C,
   D /*until Z*/
};
void f(enum Subset e)
{
   switch(e)
   {
     break;
   } //warning you miss case  B
}

Another motivation could be error code sets.

But I think this may not be practical. (So this was not my motivation)

enum error {
enum func1_error {
E1, E2
}
enum func2_error {
E1, E3
}
}


enum func2_error func2();

enum func2_error error = func2();
switch (error) {
case E1:
case E3:
break;
}

[Blue-Maned_Hawk]

Post by David Brown
Unfortunately, C does not have good
support or syntax for sum types - it all has to be handled manually and
with either extra wrapping or no type safety.

<https://github.com/Hirrolot/datatype99>

[David Brown]

Post by Blue-Maned_Hawk

Post by David Brown
Unfortunately, C does not have good
support or syntax for sum types - it all has to be handled manually and
with either extra wrapping or no type safety.

<https://github.com/Hirrolot/datatype99>

That is a fun set of macros!

[fir]

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

this is about general problem of what i name polymorphism

but maybe its not right name, it is about variety of types
and subtypes

let think abit about that

in c you got more like types not deal with subtypes
and supertypes like you got type int and type float

but they both number.. not knowing at this moment
if that "number" is subtype or supertype

dafine numeber is something you can +-&/ i mean
define some interface and what conforms is a number
(im not sure if its right but assume) then both int and
float seem to be equal types (?) i mean type is
in fact "number" and ints and floats are specific
representations.. both are somewhat 'super' above this
simpel 4operators number coz they have this exact binary
representation and interpretation low lewel people
know ..hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation

so it clearly shows that this superiority and sub-ness
(or how to call it) may be (and is) partial and inter-mixed

this all shows how this c++ polymorphism is bulshit
(which i know from first time seing it around 25 years ago)
(those sektor van skiljen tutorial times - good times)

in c as i wrote few days ago probably the interfaces
can cover those things and interfaces are kinda
natural - as function header is natuiral interface

though this would need to be organized somewhat i guess
as this interface potential is not much used now (it seems)

as to enums i dont know..but worth noticing this
supertype things not goes left-side but right-side
in structure definition i mean

point
{
int x;
int y;
}

the superiority you dont do adding things on left

chase
{
point
{
int x;
int y;
}

}


but

point
{
int x;
int y;
int chase_thing;
}

and thsi seems to be their flaw

(Its probably becouse on the left you got tree structure
avaliable - and on the right you got full combinations
avaliable

(i not rethinked it fully but noticed that things
with time and recently wrote on it in a thread on
"tree structures and polymorphism")

(and what i say is also about enums i guess, i mean
one should not define characteristic of such enums on the
left but "in" the right

is_tree
{ some_enum }


some_enum
{
is_tree;
is_short;
}

(note what i say is my oryginal work

i tell it becouse i know some people can take it not credit me,
than repeat to some other folks, who then will say "eureka"
i found much interesting thing, which comes to my mind
when soem x was saying on this (and this x took if from me)
(so just to be honest for truth)

(and by what i was inspired - i was inspired by word and idea of "tag"
(like those tags used in net)
- i just noticed that many groups of varius things you can tag
and you may organise those tags, but those tags croses over (out) the
tree
structure so tree structure for such things - i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)

[fir]

Post by fir
hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation

(typo)
i meang being "super" (not "sub") in the area of having thsi
representation (over an abstract "number" - when in fact this
"number" is not quite abstract in fact - just have its interface,
but its typical to call it abstract)

[fir]

Post by fir
- i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)

honestly i dont remember in which language i seen those interfaces,
it could be something like D or GO - some not much popular language..

strictly im not sure is somewhere people not did already this
"polymorphism" right way (bit i would probably heard, though
as i not read on programmking language news its also technicaly
possible some did something here also) (it seems to me tha flaw of
c++ like polymorphism is not spotted though or at least not
sa much as i said )

[fir]

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

this is about general problem of what i name polymorphism
but maybe its not right name, it is about variety of types
and subtypes
let think abit about that
in c you got more like types not deal with subtypes
and supertypes like you got type int and type float
but they both number.. not knowing at this moment
if that "number" is subtype or supertype
dafine numeber is something you can +-&/ i mean
define some interface and what conforms is a number
(im not sure if its right but assume) then both int and
float seem to be equal types (?) i mean type is
in fact "number" and ints and floats are specific
representations.. both are somewhat 'super' above this
simpel 4operators number coz they have this exact binary
representation and interpretation low lewel people
know ..hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation
so it clearly shows that this superiority and sub-ness
(or how to call it) may be (and is) partial and inter-mixed
this all shows how this c++ polymorphism is bulshit
(which i know from first time seing it around 25 years ago)
(those sektor van skiljen tutorial times - good times)
in c as i wrote few days ago probably the interfaces
can cover those things and interfaces are kinda
natural - as function header is natuiral interface
though this would need to be organized somewhat i guess
as this interface potential is not much used now (it seems)
as to enums i dont know..but worth noticing this
supertype things not goes left-side but right-side
in structure definition i mean
point
{
int x;
int y;
}
the superiority you dont do adding things on left
chase
{
point
{
int x;
int y;
}
}
but
point
{
int x;
int y;
int chase_thing;
}
and thsi seems to be their flaw
(Its probably becouse on the left you got tree structure
avaliable - and on the right you got full combinations
avaliable
(i not rethinked it fully but noticed that things
with time and recently wrote on it in a thread on
"tree structures and polymorphism")
(and what i say is also about enums i guess, i mean
one should not define characteristic of such enums on the
left but "in" the right
is_tree
{ some_enum }
some_enum
{
is_tree;
is_short;
}
(note what i say is my oryginal work
i tell it becouse i know some people can take it not credit me,
than repeat to some other folks, who then will say "eureka"
i found much interesting thing, which comes to my mind
when soem x was saying on this (and this x took if from me)
(so just to be honest for truth)
(and by what i was inspired - i was inspired by word and idea of "tag"
(like those tags used in net)
- i just noticed that many groups of varius things you can tag
and you may organise those tags, but those tags croses over (out) the
tree
structure so tree structure for such things - i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)

there is also ofc a fact of how this right (proper)
polymorphism would be usable as i dont know

i may maybe imagine some usecase :

say you got entities/elements (structures) sprites

each has something like x,y where its placed, on/off
state , soem may have orientation (rotation angle),
soem may be clickable and some of clicabel be type
(supertype) widgets, soem of them could be maybe soem
more advanced supertype of widgets like agents (?)

i dont know possibly this just helps a bit in composition
- depending how its done

some things can be done easy i guess

say

sprite //say simpel sprite
{
rectangle area; // like centre, and w,h
char* bacground_bitmap_name ;

int HP;
int amunition;
}

widget
{
rectangle area;
char* bacground_bitmap_name;

on_click(int x, int y) { beep();}

}

void draw_bitmap({rectangle area, char* bacground_bitmap_name}*)
{
//...
}

void register_widget({rectangle area, on_click*(int , int)}*)
{

}

foo()
{
sprite s = { {100,100,20,20}, "some.bmp", 100,20};
widget w = { {200,100,20,20}, "some.bmp" };

draw_bitmap(s); //can draw anything that has "rectangle area" and
"char* bacground_bitmap_name" - binding is compile time by names
draw_bitmap(w);

register_widget(w); //can register anything that has rectangle
area and on_click method

}

this example shows that there are functions that accepts given
structure fields and soem may pas "wider" structures into them and
they will cast down
to what they need (compiler will jus pass pointer or pointers )

the open question is if to define and name thos interfaces

like
draw_bitmap_interface
{
rectangle area,
char* bacground_bitmap_name }

and then

void draw_bitmap(draw_bitmap_interface*) {}

or meke it ad-hoc (probably both)

how much usefull? probably usefull but not much revolution it seems
(but probablu usefull)

and question is if to bind by type or by name, both coul;d be done
but if by type some typedefs need to be inwolved like

typedef {char*} bitmap_name;

sprite
{
rectangle area;
bitmap_name name;

}

maybe messy example but closes to how it can be done

[fir]

Post by fir

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

this is about general problem of what i name polymorphism
but maybe its not right name, it is about variety of types
and subtypes
let think abit about that
in c you got more like types not deal with subtypes
and supertypes like you got type int and type float
but they both number.. not knowing at this moment
if that "number" is subtype or supertype
dafine numeber is something you can +-&/ i mean
define some interface and what conforms is a number
(im not sure if its right but assume) then both int and
float seem to be equal types (?) i mean type is
in fact "number" and ints and floats are specific
representations.. both are somewhat 'super' above this
simpel 4operators number coz they have this exact binary
representation and interpretation low lewel people
know ..hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation
so it clearly shows that this superiority and sub-ness
(or how to call it) may be (and is) partial and inter-mixed
this all shows how this c++ polymorphism is bulshit
(which i know from first time seing it around 25 years ago)
(those sektor van skiljen tutorial times - good times)
in c as i wrote few days ago probably the interfaces
can cover those things and interfaces are kinda
natural - as function header is natuiral interface
though this would need to be organized somewhat i guess
as this interface potential is not much used now (it seems)
as to enums i dont know..but worth noticing this
supertype things not goes left-side but right-side
in structure definition i mean
point
{
int x;
int y;
}
the superiority you dont do adding things on left
chase
{
point
{
int x;
int y;
}
}
but
point
{
int x;
int y;
int chase_thing;
}
and thsi seems to be their flaw
(Its probably becouse on the left you got tree structure
avaliable - and on the right you got full combinations
avaliable
(i not rethinked it fully but noticed that things
with time and recently wrote on it in a thread on
"tree structures and polymorphism")
(and what i say is also about enums i guess, i mean
one should not define characteristic of such enums on the
left but "in" the right
is_tree
{ some_enum }
some_enum
{
is_tree;
is_short;
}
(note what i say is my oryginal work
i tell it becouse i know some people can take it not credit me,
than repeat to some other folks, who then will say "eureka"
i found much interesting thing, which comes to my mind
when soem x was saying on this (and this x took if from me)
(so just to be honest for truth)
(and by what i was inspired - i was inspired by word and idea of "tag"
(like those tags used in net)
- i just noticed that many groups of varius things you can tag
and you may organise those tags, but those tags croses over (out) the
tree
structure so tree structure for such things - i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)

there is also ofc a fact of how this right (proper)
polymorphism would be usable as i dont know
say you got entities/elements (structures) sprites
each has something like x,y where its placed, on/off
state , soem may have orientation (rotation angle),
soem may be clickable and some of clicabel be type
(supertype) widgets, soem of them could be maybe soem
more advanced supertype of widgets like agents (?)
i dont know possibly this just helps a bit in composition
- depending how its done
some things can be done easy i guess
say
sprite //say simpel sprite
{
rectangle area; // like centre, and w,h
char* bacground_bitmap_name ;
int HP;
int amunition;
}
widget
{
rectangle area;
char* bacground_bitmap_name;
on_click(int x, int y) { beep();}
}
void draw_bitmap({rectangle area, char* bacground_bitmap_name}*)
{
//...
}
void register_widget({rectangle area, on_click*(int , int)}*)
{
}
foo()
{
sprite s = { {100,100,20,20}, "some.bmp", 100,20};
widget w = { {200,100,20,20}, "some.bmp" };
draw_bitmap(s); //can draw anything that has "rectangle area" and
"char* bacground_bitmap_name" - binding is compile time by names
draw_bitmap(w);
register_widget(w); //can register anything that has rectangle
area and on_click method
}
this example shows that there are functions that accepts given
structure fields and soem may pas "wider" structures into them and
they will cast down
to what they need (compiler will jus pass pointer or pointers )
the open question is if to define and name thos interfaces
like
draw_bitmap_interface
{
rectangle area,
char* bacground_bitmap_name }
and then
void draw_bitmap(draw_bitmap_interface*) {}
or meke it ad-hoc (probably both)
how much usefull? probably usefull but not much revolution it seems
(but probablu usefull)
and question is if to bind by type or by name, both coul;d be done
but if by type some typedefs need to be inwolved like
typedef {char*} bitmap_name;
sprite
{
rectangle area;
bitmap_name name;
}
maybe messy example but closes to how it can be done

how it differs form c++ crap? i dont much remember c++ crap but the
difference here is slight but notable

i remember vagulelly if you have structure then you have
substructures inside which you can cast don (i dont remember
it needed to be naed, or if you can cast only to first
byte or if you get 3 substructores you can cast on each

S { A, B, C}

foo( (A) S) //downcast S to A
foo( (B) S) //downcast S to B


for sure you couldnt obtain the full combination

and if you get structure that has 3 filelds (a,b,c) you got
poteintially a lot of subtypes

a
b
c
a b
a c
b c
a b c

here you simply can cast on any subtype (and subtype is any
combination of fields (order not important i mean "a c" is same as "c a"
as "a c" constitutes interface))

so what they name "subclass" is not what they name but any interface
that you need build form any fields - it would be "subclass" for them
(not what they call subclass which is defined with that silly
class A : B or something

[Thiago Adams]

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
     enum monospaced_font_type
     {
         CASCADIA_FONT,
     },
     ARIAL_FONT
};
This could be arranged in any way.

this is about general problem of what i name polymorphism

I was considering the name polymorphic enum. But polymorphism is more
about hierarchies.

For this feature it can be any set you want. We can have duplicates.

enum E
{
enum set1 {
A
},
enum set2 {
A,
B
}
}

[fir]

Post by Thiago Adams

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

this is about general problem of what i name polymorphism

I was considering the name polymorphic enum. But polymorphism is more
about hierarchies.
For this feature it can be any set you want. We can have duplicates.
enum E
{
enum set1 {
A
},
enum set2 {
A,
B
}
}

if yu want tag enums a(And then use this tag) then this way
wouldnt work in generally as you will drown in combinatorical swamp
(and also on this i was writing before writing subtypes should
be defined on rightside

say you have real byg set of enums and you got 10 suptypes (tags) (A B C
D E F G H I J) of
enyms each one have about 100 enums of that tag you then need
to define also types that have combination of tags AB AJ AD F G FGJ BD
BG ....

and youre drowned

i dont know hovewer what you need to do as you write this way one could
sit and think what youre talking about - and i got no time
(typical for programming groups though and what i write is also
probably of this kind - describing some things in programming may be
quite hermetic to read)

as to enums i dislike them a lot.. realy sometimes is better tu use
'asd' and sometimes even strings and comepare by strcomp

[fir]

Post by fir
as to enums i dislike them a lot.. realy sometimes is better tu use
'asd' and sometimes even strings and comepare by strcomp

im not sure though how to make 'shgshg' (name it a char literal form of
adhoc enums or tags) up to 8 chars work as 8 chars would suffice in many
cases

asked but no one answered

long long unsigned tag ;

void foo(long long unsigned tag)
{
if(tag=='warsaw') printf("warsaw");
if(tag=='paris') printf("paris");
if(tag=='new york') printf("new york");


}


foo('paris');

[Bonita Montero]

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
    enum monospaced_font_type
    {
        CASCADIA_FONT,
    },
    ARIAL_FONT
};
This could be arranged in any way.

Use C++:

struct font_type
{
struct monospaced_font_type
{
static constexpr int CASCADIA_FONT = 123;
};
static constexpr int ARIAL_FONT = 456;

};

[Thiago Adams]

Post by Bonita Montero

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
     enum monospaced_font_type
     {
         CASCADIA_FONT,
     },
     ARIAL_FONT
};
This could be arranged in any way.

struct font_type
{
    struct monospaced_font_type
    {
        static constexpr int CASCADIA_FONT = 123;
    };
    static constexpr int ARIAL_FONT = 456;
};

It would not help the switch case warnings.

[fir]

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want

i guess you maybe say what i understand as kinda "micro dictionary"

i mean say 32 bits of enum offes space to give some section for
"keys" and some section for "values" (for example upper 8 bits
for keys 1-255 enumized or not - and 24 bits for values - also enumized
or not...such microdictionary is good idea..i guess people
sometimes use it but in fact enum statement dont support it afair

though as i said the form of defining it

enum
{
AJHJH
{
KJHZ,
HJKJHG,
HJHJH,
}
AJJHKJH
{
KJHZ,
HJKJHG,
HJHJH,
}

}

may be probably bad becouse you want to have 2 keys so
it should be more like

enum A:shbshb
enum B:shbshbskjs
enum B:shbshbjskj
enum A:B:shbshbskjs

[fir]

Post by fir
may be probably bad becouse you want to have 2 keys so
it should be more like
enum A:shbshb
enum B:shbshbskjs
enum B:shbshbjskj
enum A:B:shbshbskjs

maybe i wrote it kinda bad i mean key section has its aenum
with values sasy A B C D E F and value section has various
lists of enums for each key - not sure it is to name set as
its ordered its more liek list imo

also one can have more keys - so this may be even dictionary whose
has say 2-dimensional array of keys and arrays as values

so small number but the definition of it could take gigabytes

[Thiago Adams]

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
     enum monospaced_font_type
     {
         CASCADIA_FONT,
     },
     ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want
i guess you maybe say what i understand as kinda "micro dictionary"

It does not use bits. Each enumerator will have a sequential number
like it is today.

When the same enumerator is used twice the number does not change.

Sample:

enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},

ARIAL_FONT,

enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};



CASCADIA_FONT is 0
ARIAL_FONT is 1



The implementation could work like this:

Each enum has a set of "parent enums."

A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.

For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.

Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .

Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.

In a switch case for an enum type, we must ensure that all enumerators
of that type are present.

For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are included.

[fir]

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want
i guess you maybe say what i understand as kinda "micro dictionary"

It does not use bits. Each enumerator will have a sequential number like
it is today.
When the same enumerator is used twice the number does not change.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are included.

ok i guess i undestand what you talkin about

you want a list of enums say from 0 to 1703 ordinally on binary level
but but you also want to compiler build a table to which group it belong
but not encode it as bits

if so if you want to repeat given emon in more groups than you need to
not give it new walue instead given enum would have two walues

it can be done and gives something like more typesafety but the
microdictionary is imo much more interesting idea - as those dictionary
things are in a way fundamental in programming

[fir]

Post by fir

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want
i guess you maybe say what i understand as kinda "micro dictionary"

It does not use bits. Each enumerator will have a sequential number like
it is today.
When the same enumerator is used twice the number does not change.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are included.

ok i guess i undestand what you talkin about
you want a list of enums say from 0 to 1703 ordinally on binary level
but but you also want to compiler build a table to which group it belong
but not encode it as bits
if so if you want to repeat given emon in more groups than you need to
not give it new walue instead given enum would have two walues
it can be done and gives something like more typesafety but the
microdictionary is imo much more interesting idea - as those dictionary
things are in a way fundamental in programming

overaly i would said this is good idea - but its generalisation: much
better (could said weird i never thought concretely on this
microdictionaries though i dropped thinking on C for months completely)

[fir]

Post by fir

Post by fir

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want
i guess you maybe say what i understand as kinda "micro dictionary"

It does not use bits. Each enumerator will have a sequential number like
it is today.
When the same enumerator is used twice the number does not change.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are included.

ok i guess i undestand what you talkin about
you want a list of enums say from 0 to 1703 ordinally on binary level
but but you also want to compiler build a table to which group it belong
but not encode it as bits
if so if you want to repeat given emon in more groups than you need to
not give it new walue instead given enum would have two walues
it can be done and gives something like more typesafety but the
microdictionary is imo much more interesting idea - as those dictionary
things are in a way fundamental in programming

overaly i would said this is good idea - but its generalisation: much
better (could said weird i never thought concretely on this
microdictionaries though i dropped thinking on C for months completely)

i could say i once used something that resembles this dictionary this is
gamma table

unsigned char gamma_table[256] =
{
51,54,60,63, 68,70,73,77, 82,83,84,86, 88,90,92,95,
98,99,100,101, 102,103,104,106, 108,109,110,111, 113,115,117,120,
122,122,123,124, 124,125,126,127, 128,129,130,131, 132,133,134,136,
137,137, 138,139, 140,141,142,143, 144,145,146,147, 148,150,152,153,

154,154,154,155, 155,155,156,156, 157,157,158,158, 159,159,160,160,
161,161,161,162, 162,163,163,164, 164,165,166,167, 168,169,170,171,
172,172,173,173, 174,174,175,175, 176,176,177,177, 178,178,179,179,
180,180,181,181, 182,182,183,183, 184,185,186,187, 188,189,190,191,

192,192,192,193, 193,193,194,194, 194,195,195,196, 196,197,197,198,
198,198,198,199, 199,199,200,200, 201,201,202,202, 203,204,205,206,
207,207,207,208, 208,208,209,209, 210,210,211,211, 212,212,213,214,
214,214,214,215, 215,215,216,216, 217,217,218,219, 220,221,222,223,

224,224,224,225, 225,225,225,226, 226,226,227,227, 228,228,229,229,
230,230,230,231, 231,231,232,232, 233,233,234,234, 235,235,236,237,
238,238,238,239, 239,239,240,240, 241,241,242,242, 243,243,244,245,
246,246,246,247, 247,247,248,248, 249,249,250,251, 252,253,254,255


};

but definig it as such microdictionarry seem to be probably better idea

[fir]

how to define such microdictionary i dont know

it could be (speaking on old c style) something like

dictionary int some[int];

some[110]=10;
some['kot']='dog';

some[enum lalla]=enum bababa;

such int-int implementation would need 64 bit value
those entries abowe would be 3 64 bit numbers


more entries for one key, no problem

some['kot']='mors';

just another number added

(so possibly two types of dictionaries can be defined if not more


also i gues bitfields can be used


dictionary signed:10 some[signed:22];

also such syntax probably is acceptable

dictionary void some[signed:22][signed:10];


some[29][233];

now this is container that stores void

[fir]

Post by fir
how to define such microdictionary i dont know
it could be (speaking on old c style) something like
dictionary int some[int];
some[110]=10;
some['kot']='dog';
some[enum lalla]=enum bababa;
such int-int implementation would need 64 bit value
those entries abowe would be 3 64 bit numbers
more entries for one key, no problem
some['kot']='mors';
just another number added
(so possibly two types of dictionaries can be defined if not more
also i gues bitfields can be used
dictionary signed:10 some[signed:22];
also such syntax probably is acceptable
dictionary void some[signed:22][signed:10];
some[29][233];
now this is container that stores void

some curiosity is that it seems that normal array can be 'directoried'
- turn in directory

say you got array

int tab[200];

array is a directory that kas one key form 0=199 and one int value per
key )jas its start adress and ocupies 200 ints of ram)

say you add a method to not revrite value under key but add one

tab[22]:= 100
tab[22]:= 120
tab[22]:= 100

this can be done by just adding 3 64 bit values on a side
and this construct would be a mix of array and dict made
by list of key-values the underlying implementation may
also be different liek array of seeds to heap based arrays too)

overally c needs such builtin dictionary a lot

[fir]

Post by fir

Post by Thiago Adams
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.

reading yet once i dont know what you want
i guess you maybe say what i understand as kinda "micro dictionary"
i mean say 32 bits of enum offes space to give some section for
"keys" and some section for "values" (for example upper 8 bits
for keys 1-255 enumized or not - and 24 bits for values - also enumized
or not...such microdictionary is good idea..i guess people
sometimes use it but in fact enum statement dont support it afair
though as i said the form of defining it
enum
{
AJHJH
{
KJHZ,
HJKJHG,
HJHJH,
}
AJJHKJH
{
KJHZ,
HJKJHG,
HJHJH,
}
}
may be probably bad becouse you want to have 2 keys so
it should be more like
enum A:shbshb
enum B:shbshbskjs
enum B:shbshbjskj
enum A:B:shbshbskjs

wonder if such micro dictionary should hovever be called enom
it is dictionary but micro

dict T1 'a' = 0x8989 , 'b' = 0x2989 , 'c' = 0x8289 ,t T1 'd' = 0x8933,
'e' = 0x89d9, 'f' = 0x898d;, 'b':1 = 0xffff

ads few entries to micro dictionary named T1

then T1('a') would yeild to 0x8989

then T1('b') would eventually yeild to {0x2989, 0xffff }