For my compiler, I added syntax to enums to allow using an enum to define one-hot values. This allows the use of the BBS/BBC instruction by the compiler in some cases.

The syntax is to place the generator expression in round brackets after the enum keyword. Without the generator expression an expression of (1) is assumed. This should not break any existing source code.

Some examples:
1)
enum (-1) { a, b, c, d, e };

Generates the values 0, -1, -2, -3, -4 for a,b,c,d,e respectively.

2)
enum (3) { a, b, c, d, e};
Generates the values 0, 3, 6, 9, 12 for a,b,c,d,e respectively.

3)
enum (2*) { a, b, c, d, e};

Generates the values 0,1,2,4,8 to a,b,c,d,e respectively.
The (2*) is the multiplicative increment spec. (3*, 4*, etc is also possible).

4)
enum (2*) { a = 3, b, c, d, e};
Generates the values 3, 6, 12, 24, and 48 for a, b, c, d, e.

On 30/09/2021 23:26, Robert Finch wrote:
> For my compiler, I added syntax to enums to allow using an enum to define one-hot values. This allows the use of the BBS/BBC instruction by the compiler in some cases.
>
> The syntax is to place the generator expression in round brackets after the enum keyword. Without the generator expression an expression of (1) is assumed. This should not break any existing source code.
>
> Some examples:
> 1)
> enum (-1) { a, b, c, d, e };
>
> Generates the values 0, -1, -2, -3, -4 for a,b,c,d,e respectively.
>
> 2)
> enum (3) { a, b, c, d, e};
> Generates the values 0, 3, 6, 9, 12 for a,b,c,d,e respectively.
>
> 3)
> enum (2*) { a, b, c, d, e};
>
> Generates the values 0,1,2,4,8 to a,b,c,d,e respectively.
> The (2*) is the multiplicative increment spec. (3*, 4*, etc is also possible).
>
> 4)
> enum (2*) { a = 3, b, c, d, e};
> Generates the values 3, 6, 12, 24, and 48 for a, b, c, d, e.
>

What would be the use-cases for these? Real one-hot enumerations
(0b001, 0b0010, 0b0100, 0b1000, etc.) are sometimes useful in
programmable logic since they can be handled quickly in hardware. But
any kind of C to VHDL or other tool for writing programmable logic in C
already has dozens of extensions to handle that kind of thing (if it
can't do it automatically).

What processor(s) are you targeting where you can get measurably more
efficient code from any of these cases? Even for a proper one-hot
enumeration - "enum (2*) { a = 1, b, c, d, e };" in your syntax, and
missing from your examples - and even with the equivalent of a "default
: __builtin_unreachable();" default clause, I have trouble imagining how
it would lead to any improvement.

Alternatively, where do you imagine such syntaxes being useful to the
programmer?

Adding new syntaxes and extensions to a language is not cost-free, even
if it is easy to implement in the tool. It means you have to document
and support steadily more obscure features just in case someone used it
in code in the past, even if no one remembers what it means now.

(It's your language, your tool, and your decision - I'm just pushing you
to think it through.)

On Friday, October 1, 2021 at 3:38:29 AM UTC-4, David Brown wrote:
> On 30/09/2021 23:26, Robert Finch wrote:
> > For my compiler, I added syntax to enums to allow using an enum to define one-hot values. This allows the use of the BBS/BBC instruction by the compiler in some cases.
> >
> > The syntax is to place the generator expression in round brackets after the enum keyword. Without the generator expression an expression of (1) is assumed. This should not break any existing source code.
> >
> > Some examples:
> > 1)
> > enum (-1) { a, b, c, d, e };
> >
> > Generates the values 0, -1, -2, -3, -4 for a,b,c,d,e respectively.
> >
> > 2)
> > enum (3) { a, b, c, d, e};
> > Generates the values 0, 3, 6, 9, 12 for a,b,c,d,e respectively.
> >
> > 3)
> > enum (2*) { a, b, c, d, e};
> >
> > Generates the values 0,1,2,4,8 to a,b,c,d,e respectively.
> > The (2*) is the multiplicative increment spec. (3*, 4*, etc is also possible).
> >
> > 4)
> > enum (2*) { a = 3, b, c, d, e};
> > Generates the values 3, 6, 12, 24, and 48 for a, b, c, d, e.
> >
> What would be the use-cases for these? Real one-hot enumerations
> (0b001, 0b0010, 0b0100, 0b1000, etc.) are sometimes useful in
> programmable logic since they can be handled quickly in hardware. But
> any kind of C to VHDL or other tool for writing programmable logic in C
> already has dozens of extensions to handle that kind of thing (if it
> can't do it automatically).
>
> What processor(s) are you targeting where you can get measurably more
> efficient code from any of these cases? Even for a proper one-hot
> enumeration - "enum (2*) { a = 1, b, c, d, e };" in your syntax, and
> missing from your examples - and even with the equivalent of a "default
> : __builtin_unreachable();" default clause, I have trouble imagining how
> it would lead to any improvement.
>
> Alternatively, where do you imagine such syntaxes being useful to the
> programmer?
>
>
> Adding new syntaxes and extensions to a language is not cost-free, even
> if it is easy to implement in the tool. It means you have to document
> and support steadily more obscure features just in case someone used it
> in code in the past, even if no one remembers what it means now.
>
> (It's your language, your tool, and your decision - I'm just pushing you
> to think it through.)

I thought being able to generate values might be useful for generating series coefficients for polynomials. That would work better if floats could be defined.
I found the syntax useful for defining error message constants less than zero. If the return value is less than zero then it is an error otherwise it is a valid status.

I also found it useful to allow the BBS / BBC instructions to be used. I defined a set of button presses to be 1,2,4,8,16 for each button respectively.. That way if more than one button is pressed at the same time then a code is generated for that case.
BBS/BBC instructions encode the constant directly in the branch instruction.. Otherwise, a compare then a branch instruction is required to test. This is a single instruction versus two instructions for compare then branch. So, it is both faster and shorter. Most architectures do not have a compare-to-immediate and branch instruction. Whether it is measurably different or not IDK.

I made a slight mistake in my previous example. If the generator is multiplicative then the enumeration automatically starts at one. I also changed the syntax to place the ‘*’ before the constant.

Language obscurity is an issue. The way the generator is introduced it is an optional part of the enum that does not have to be present in the code. One does not need to know about it until it is seen in the code. Then one may need to look it up in the manual.

On 01/10/2021 17:06, Robert Finch wrote:
> On Friday, October 1, 2021 at 3:38:29 AM UTC-4, David Brown wrote:
>> On 30/09/2021 23:26, Robert Finch wrote:
>>> For my compiler, I added syntax to enums to allow using an enum
>>> to define one-hot values. This allows the use of the BBS/BBC
>>> instruction by the compiler in some cases.
>>>
>>> The syntax is to place the generator expression in round brackets
>>> after the enum keyword. Without the generator expression an
>>> expression of (1) is assumed. This should not break any existing
>>> source code.
>>>
>>> Some examples: 1) enum (-1) { a, b, c, d, e };
>>>
>>> Generates the values 0, -1, -2, -3, -4 for a,b,c,d,e
>>> respectively.
>>>
>>> 2) enum (3) { a, b, c, d, e}; Generates the values 0, 3, 6, 9, 12
>>> for a,b,c,d,e respectively.
>>>
>>> 3) enum (2*) { a, b, c, d, e};
>>>
>>> Generates the values 0,1,2,4,8 to a,b,c,d,e respectively. The
>>> (2*) is the multiplicative increment spec. (3*, 4*, etc is also
>>> possible).
>>>
>>> 4) enum (2*) { a = 3, b, c, d, e}; Generates the values 3, 6, 12,
>>> 24, and 48 for a, b, c, d, e.
>>>
>> What would be the use-cases for these? Real one-hot enumerations
>> (0b001, 0b0010, 0b0100, 0b1000, etc.) are sometimes useful in
>> programmable logic since they can be handled quickly in hardware.
>> But any kind of C to VHDL or other tool for writing programmable
>> logic in C already has dozens of extensions to handle that kind of
>> thing (if it can't do it automatically).
>>
>> What processor(s) are you targeting where you can get measurably
>> more efficient code from any of these cases? Even for a proper
>> one-hot enumeration - "enum (2*) { a = 1, b, c, d, e };" in your
>> syntax, and missing from your examples - and even with the
>> equivalent of a "default : __builtin_unreachable();" default
>> clause, I have trouble imagining how it would lead to any
>> improvement.
>>
>> Alternatively, where do you imagine such syntaxes being useful to
>> the programmer?
>>
>>
>> Adding new syntaxes and extensions to a language is not cost-free,
>> even if it is easy to implement in the tool. It means you have to
>> document and support steadily more obscure features just in case
>> someone used it in code in the past, even if no one remembers what
>> it means now.
>>
>> (It's your language, your tool, and your decision - I'm just
>> pushing you to think it through.)
>
> I thought being able to generate values might be useful for
> generating series coefficients for polynomials. That would work
> better if floats could be defined. I found the syntax useful for
> defining error message constants less than zero. If the return value
> is less than zero then it is an error otherwise it is a valid
> status.
>

These are things you do /once/. You don't make a feature or extension
in a programming language to save a dozen keystrokes in the source code.

> I also found it useful to allow the BBS / BBC instructions to be
> used. I defined a set of button presses to be 1,2,4,8,16 for each
> button respectively. That way if more than one button is pressed at
> the same time then a code is generated for that case. BBS/BBC
> instructions encode the constant directly in the branch instruction.
> Otherwise, a compare then a branch instruction is required to test.
> This is a single instruction versus two instructions for compare then
> branch. So, it is both faster and shorter. Most architectures do not
> have a compare-to-immediate and branch instruction. Whether it is
> measurably different or not IDK.

Again - what is your target architecture?

And note that if you testing just one bit when several might be set, you
are no longer talking about a switch statement.

>
> I made a slight mistake in my previous example. If the generator is
> multiplicative then the enumeration automatically starts at one. I
> also changed the syntax to place the ‘*’ before the constant.
>
> Language obscurity is an issue. The way the generator is introduced
> it is an optional part of the enum that does not have to be present
> in the code. One does not need to know about it until it is seen in
> the code. Then one may need to look it up in the manual.
>

Assume that no one reads the manuals, and assume that features that are
rarely used are incomprehensible and confusing to people using the
language. Like it or not, that is the reality. Ask 1000 experienced C
programmers what "static" or an asterix in an array specifier in a
function declaration means. The number of people who could tell you
could be counted on one hand. The number who have actually /used/ those
language features could probably be counted on one finger. Obscure and
rarely useful features are not a good idea unless they give a serious
and significant benefit that cannot be achieved in more normal and
obvious ways.

There are, or have been, a number of people in this group that have made
or are making their own languages. They are the only people who ever
use the tools, they designed their language(s), they wrote their
tool(s). They made their language according to their own person ideas
of what makes a "perfect" language. And without exception (AFAIK), they
forget details, forget what features they do or do not have, forget how
things work. That's not a criticism of these language creators - it is,
I think, an inevitable consequence of doing the design on their own
without discussing ideas with others, and without the benefit of having
multiple people try out the language in practice.

On Friday, October 1, 2021 at 1:03:55 PM UTC-4, David Brown wrote:
> On 01/10/2021 17:06, Robert Finch wrote:
> > On Friday, October 1, 2021 at 3:38:29 AM UTC-4, David Brown wrote:
> >> On 30/09/2021 23:26, Robert Finch wrote:
> >>> For my compiler, I added syntax to enums to allow using an enum
> >>> to define one-hot values. This allows the use of the BBS/BBC
> >>> instruction by the compiler in some cases.
> >>>
> >>> The syntax is to place the generator expression in round brackets
> >>> after the enum keyword. Without the generator expression an
> >>> expression of (1) is assumed. This should not break any existing
> >>> source code.
> >>>
> >>> Some examples: 1) enum (-1) { a, b, c, d, e };
> >>>
> >>> Generates the values 0, -1, -2, -3, -4 for a,b,c,d,e
> >>> respectively.
> >>>
> >>> 2) enum (3) { a, b, c, d, e}; Generates the values 0, 3, 6, 9, 12
> >>> for a,b,c,d,e respectively.
> >>>
> >>> 3) enum (2*) { a, b, c, d, e};
> >>>
> >>> Generates the values 0,1,2,4,8 to a,b,c,d,e respectively. The
> >>> (2*) is the multiplicative increment spec. (3*, 4*, etc is also
> >>> possible).
> >>>
> >>> 4) enum (2*) { a = 3, b, c, d, e}; Generates the values 3, 6, 12,
> >>> 24, and 48 for a, b, c, d, e.
> >>>
> >> What would be the use-cases for these? Real one-hot enumerations
> >> (0b001, 0b0010, 0b0100, 0b1000, etc.) are sometimes useful in
> >> programmable logic since they can be handled quickly in hardware.
> >> But any kind of C to VHDL or other tool for writing programmable
> >> logic in C already has dozens of extensions to handle that kind of
> >> thing (if it can't do it automatically).
> >>
> >> What processor(s) are you targeting where you can get measurably
> >> more efficient code from any of these cases? Even for a proper
> >> one-hot enumeration - "enum (2*) { a = 1, b, c, d, e };" in your
> >> syntax, and missing from your examples - and even with the
> >> equivalent of a "default : __builtin_unreachable();" default
> >> clause, I have trouble imagining how it would lead to any
> >> improvement.
> >>
> >> Alternatively, where do you imagine such syntaxes being useful to
> >> the programmer?
> >>
> >>
> >> Adding new syntaxes and extensions to a language is not cost-free,
> >> even if it is easy to implement in the tool. It means you have to
> >> document and support steadily more obscure features just in case
> >> someone used it in code in the past, even if no one remembers what
> >> it means now.
> >>
> >> (It's your language, your tool, and your decision - I'm just
> >> pushing you to think it through.)
> >
> > I thought being able to generate values might be useful for
> > generating series coefficients for polynomials. That would work
> > better if floats could be defined. I found the syntax useful for
> > defining error message constants less than zero. If the return value
> > is less than zero then it is an error otherwise it is a valid
> > status.
> >
> These are things you do /once/. You don't make a feature or extension
> in a programming language to save a dozen keystrokes in the source code.
> > I also found it useful to allow the BBS / BBC instructions to be
> > used. I defined a set of button presses to be 1,2,4,8,16 for each
> > button respectively. That way if more than one button is pressed at
> > the same time then a code is generated for that case. BBS/BBC
> > instructions encode the constant directly in the branch instruction.
> > Otherwise, a compare then a branch instruction is required to test.
> > This is a single instruction versus two instructions for compare then
> > branch. So, it is both faster and shorter. Most architectures do not
> > have a compare-to-immediate and branch instruction. Whether it is
> > measurably different or not IDK.
> Again - what is your target architecture?
>
> And note that if you testing just one bit when several might be set, you
> are no longer talking about a switch statement.
> >
> > I made a slight mistake in my previous example. If the generator is
> > multiplicative then the enumeration automatically starts at one. I
> > also changed the syntax to place the ‘*’ before the constant.
> >
> > Language obscurity is an issue. The way the generator is introduced
> > it is an optional part of the enum that does not have to be present
> > in the code. One does not need to know about it until it is seen in
> > the code. Then one may need to look it up in the manual.
> >
> Assume that no one reads the manuals, and assume that features that are
> rarely used are incomprehensible and confusing to people using the
> language. Like it or not, that is the reality. Ask 1000 experienced C
> programmers what "static" or an asterix in an array specifier in a
> function declaration means. The number of people who could tell you
> could be counted on one hand. The number who have actually /used/ those
> language features could probably be counted on one finger. Obscure and
> rarely useful features are not a good idea unless they give a serious
> and significant benefit that cannot be achieved in more normal and
> obvious ways.
>
> There are, or have been, a number of people in this group that have made
> or are making their own languages. They are the only people who ever
> use the tools, they designed their language(s), they wrote their
> tool(s). They made their language according to their own person ideas
> of what makes a "perfect" language. And without exception (AFAIK), they
> forget details, forget what features they do or do not have, forget how
> things work. That's not a criticism of these language creators - it is,
> I think, an inevitable consequence of doing the design on their own
> without discussing ideas with others, and without the benefit of having
> multiple people try out the language in practice.

The target architecture is one of several custom designs which include BBS / BBC instructions. Most recently I have been working on ANY1. I have also ported the compiler to generate PowerPC code and RISCV code. The PowerPC version does not yet make use of all processor features like update addressing and the loop counter.

On 01/10/2021 18:03, David Brown wrote:
> On 01/10/2021 17:06, Robert Finch wrote:

> There are, or have been, a number of people in this group that have made
> or are making their own languages. They are the only people who ever
> use the tools, they designed their language(s), they wrote their
> tool(s). They made their language according to their own person ideas
> of what makes a "perfect" language.

In my case, development has been driven by specific needs. I was not, at
the time, creating a general purpose language for anyone to use and on
any computer.

It happens that by now, my language can /easily/ do anything C can do,
so if that is general purpose, then so is mine.

And I don't consider my language perfect otherwise I would have stopped
development long ago.

For example, I've had my module system for quite a few years (C++ is
just acquiring one). Long enough to discover its problems. I'm just
about to overhaul it and may even do away with it because I have ideas
for a different, and better, approach.

> And without exception (AFAIK), they
> forget details, forget what features they do or do not have, forget how
> things work.

I can tell you one thing I don't forget: it is how to write a complex
type declaration. That's because there is nothing to remember about it.

> That's not a criticism of these language creators - it is,
> I think, an inevitable consequence of doing the design on their own
> without discussing ideas with others, and without the benefit of having
> multiple people try out the language in practice.

I've used mine on myriad projects over 40 years; you get to see what
works well and what doesn't; what's needed and what isn't; what belongs
in this language, and what is better off in the next language up.

I suspect the feedback from people, who might have been used to a
different language (like C), will be mainly why doesn't it have feature
X, Y and Z from that other language.

Fortunately I don't need to pander to anybody else.