On Sunday, January 22, 2023 at 7:30:12 PM UTC-3, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
> > On 1/22/2023 1:43 PM, Ben Bacarisse wrote:
> >> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >>
> >>> On 1/22/2023 7:54 AM, Ben Bacarisse wrote:
> >>>> Thiago Adams <thiago...@gmail.com> writes:
> >>>>
> >>>>> On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
> >>>>>> On Friday, January 20, 2023 at 8:41:16 PM UTC+2, Thiago Adams wrote:
> >>>>>>> At first edition of "The C programming language" we can see
> >>>>>>> that structs could not be passed directly as function arguments.
> >>>>>>> They also could not be returned from functions and assigned.
> >>>>>>>
> >>>>>>> Soon after [1], the language changed to allow assignment and make
> >>>>>>> structs arguments passed by copy by default.
> >>>>>>>
> >>>>>>> Today, I have 0% of structs being passed by copy in my code.
> >>>>>>> So for me this is a very bad default.
> >>>>>>>
> >>>>>>> If structs where passed by reference this would not be the only
> >>>>>>> exception on the type system because arrays are already passed
> >>>>>>> as pointers.
> >>>>>>>
> >>>>>>> Do you have structs passed by copy in your code?
> >>>>>> Yes, I do.
> >>>>>>> Could it be replaced by const * ?
> >>>>>> Not 100%
> >>>>>>> Considering your answer would you agree with me that this is a bad default?
> >>>>>> No, it is the only sane option.
> >>>>>> The early C that didn't have it was inconsistent.
> >>>>>> And I don't understand why do you call it "default'.
> >>>>>
> >>>>> I guess the other option was to make structs arguments passed by
> >>>>> reference. The same for arrays.
> >>>>
> >>>> (I'd say "and the same for arrays". As it stands, it could sound like
> >>>> you think arrays are currently "passed by reference". I know you don;t
> >>>> think that, but it's a common enough misconception that you'd want to
> >>>> avoid any hint of it.)
> >>>>
> >>>>> void f(struct X x, int a[2]) {
> >>>>> // sizeof(x) and sizeof(a) would not be sizeof pointer
> >>>>> }
> >>>>>
> >>>>> no need for -> everywhere inside structs.
> >>>> And now you have a different anomaly in the language. Everything except
> >>>> structs and arrays are passed by reference.
> >>>
> >>> I must be misunderstanding you here.
> >> No, you are understand what I wrote but I wrote the wrong thing. I
> >> meant to write "by value". It's a common mistake I make. I write it
> >> one way, then edit in a way that makes things clearer but sometimes I
> >> forget to edit a key part, and "except" or a "not" or an "otherwise"!
> >>
> >>> ? Where did I misunderstand you Ben?
> >>
> >> Nowhere! Thanks for spotting it.
> >> "And now you have a different anomaly in the language. Everything
> >> except structs and arrays are passed by value."
> >
> > Can't a struct be passed by value? I see the _except_ clause in your
> > sentence. Some quick code typed in the damn newsreader, sorry for any
> > typos!
> In current C, yes, but I was commenting on TA's suggestion that passing
> of structs and arrays should be changed.

I don´t have a suggestion to change C right now, because of the impact
of existing code that is modifying a copy of the argument.

>In TA's suggestion, these
> would be always be passed by reference. He seemed to want to tidy
> something up, but the effect is to create a new anomaly.
>
> May I should have said "would be" rather than "are" to keep it clear
> that I am talking about a hypothetical language.
>
Yes I am talking about a time machine. If I was there I would recommend
by reference.
I searched but I didn't find the rationally for structs by value and
arrays (similar of references). We can just imagine some reasons.
Maybe it would broke some existing code for arrays for instance. And not
for structs because structs were not allowed in arguments.

I also would like to know the decision of this decorative array on arguments.
And also why when in C99 they added [static N] in arrays instead of just
making the past decorative syntax behave like [static N].

On 23/01/2023 01:01, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 1/22/23 16:27, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> ...
>>>> Just as it is extremely common for numbers to be pure-real, with no
>>>> imaginary part, it is not uncommon, when doing physics or engineering
>>>> using complex values, to have some of those quantities being calculated
>>>> to be guaranteed to be pure imaginary. Storing such quantities using
>>>> _Imaginary types reduces the space required by a factor of 2, which can
>>>> be important if you have huge arrays of them (not an uncommon feature of
>>>> physics/engineering programs). More importantly, I think, is that use of
>>>> such types should enable warnings about questionable uses of such types,
>>>> such as taking the Real part of them.
>>>>
>>>> It's certainly not impossible to work with such quantities efficiently
>>>> without using the _Imaginary types - before the introduction of those
>>>> types, they could have been stored as real values, with a comment
>>>> indicating that these real values are the imaginary component of the
>>>> actual value. However, making _Imaginary a part of the declaration of
>>>> such objects is better than relying upon people to notice such a comment.
>>>
>>> Thanks, I didn't know that.
>>>
>>> Given that imaginary types are useful, I wonder why they're not
>>> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports
>>> `_Imaginary double`.
>>>
>>> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
>>> Annex G correctly implies that they're required to support imaginary
>>> types.
>
> I was wrong about this; see below.
>
>> I said that they could be useful. I didn't address how useful they would
>> be. I don't imagine that the usefulness is great. I hope the committee
>> had some evidence of actual demand for such a feature before deciding to
>> add it to the language.
>
> There are still a few things I'm curious about:
>
> Why did the committee choose to make complex numbers mandatory and
> imaginary numbers optional? I wouldn't expect imaginary numbers
> to be very difficult to implement once you have complex numbers.
> Nor would I expect users of one C implementation to have a greater
> need for them than users of another (which would have been a
> reasonable basis for making them optional).
>

I also wonder why the committee choose to make complex numbers mandatory
in C99, then optional in C11. Complex numbers are not particularly hard
to implement (once you have all the rest of floating point support and
<math.h>), and on the user side they are zero cost if you don't use them.

> Have any C compilers implemented _Imaginary? (If not, it seems
> like a failed experiment.)
>

I note that C++ does not have a standard library "imaginary" type
either. I suppose there simply hasn't been much call for such a type in
practice - you can always handle them yourself using real types, as long
as you are careful about usage in expressions. (And in C++, you could
easily make a wrapper class so you don't have to be careful!)

On 23/01/2023 04:06, Thiago Adams wrote:
> On Sunday, January 22, 2023 at 7:30:12 PM UTC-3, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>

>>> Can't a struct be passed by value? I see the _except_ clause in your
>>> sentence. Some quick code typed in the damn newsreader, sorry for any
>>> typos!
>> In current C, yes, but I was commenting on TA's suggestion that passing
>> of structs and arrays should be changed.
>
> I don´t have a suggestion to change C right now, because of the impact
> of existing code that is modifying a copy of the argument.
>
Surely the solution is simple (assuming you are happy making a compiler
for a non-standard modified C)? Add references in the style of C++.
Then existing code will work fine as it is, and if you want to pass
structs by reference, you can do so by declaring the appropriate
parameter as a reference parameter. You get the best of both worlds,
while using a syntax and concepts that are already familiar to many people.

Thiago Adams <thiago.adams@gmail.com> writes:

> On Sunday, January 22, 2023 at 12:54:28 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
>> >> On Friday, January 20, 2023 at 8:41:16 PM UTC+2, Thiago Adams wrote:
>> >> > At first edition of "The C programming language" we can see
>> >> > that structs could not be passed directly as function arguments.
>> >> > They also could not be returned from functions and assigned.
>> >> >
>> >> > Soon after [1], the language changed to allow assignment and make
>> >> > structs arguments passed by copy by default.
>> >> >
>> >> > Today, I have 0% of structs being passed by copy in my code.
>> >> > So for me this is a very bad default.
>> >> >
>> >> > If structs where passed by reference this would not be the only
>> >> > exception on the type system because arrays are already passed
>> >> > as pointers.
>> >> >
>> >> > Do you have structs passed by copy in your code?
>> >> Yes, I do.
>> >> > Could it be replaced by const * ?
>> >> Not 100%
>> >> > Considering your answer would you agree with me that this is a bad default?
>> >> No, it is the only sane option.
>> >> The early C that didn't have it was inconsistent.
>> >> And I don't understand why do you call it "default'.
>> >
>> > I guess the other option was to make structs arguments passed by
>> > reference. The same for arrays.
>> (I'd say "and the same for arrays". As it stands, it could sound like
>> you think arrays are currently "passed by reference". I know you don;t
>> think that, but it's a common enough misconception that you'd want to
>> avoid any hint of it.)
>> > void f(struct X x, int a[2]) {
>> > // sizeof(x) and sizeof(a) would not be sizeof pointer
>> > }
>
> It works as if arrays were reference. Like
>
> void f(int a[2]){
> a[0] = 1;
> }
> int main() {
> int a[2] = {0};
> f(a);
> assert(a[0] == 1);
> }
>
> And no need for address of.
>
>> > no need for -> everywhere inside structs.
>>
>> And now you have a different anomaly in the language. Everything except
>> structs and arrays are passed by [value].

(I have corrected my editing error in the above.)

> Don`t you think arrays already look like an anomaly? See the sample
> above.

Yes, they are. My point is you switch one for another so I don't see
the point.

And your suggestion does address what happens with arrays in /other/
contexts, so it's possible you are, in fact, adding a new anomaly to the
exiting array one. At least arrays are widely anomalous -- it's not
just when passed to functions that array names decay to pointers. You
have to lean this peculiarity in about lesson two when learning C!

--
Ben.

David Brown <david.brown@hesbynett.no> writes:
[...]
> I also wonder why the committee choose to make complex numbers
> mandatory in C99, then optional in C11. Complex numbers are not
> particularly hard to implement (once you have all the rest of floating
> point support and <math.h>), and on the user side they are zero cost
> if you don't use them.

I had forgotten that C11 made complex numbers optional. I agree that it
was an odd decision, as was making VLAs optional.

Making a feature optional could be a good first step towards making it
mandatory in a future edition of the standard. Making an existing
mandatory feature optional makes less sense to me.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 23/01/2023 21:15, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I also wonder why the committee choose to make complex numbers
>> mandatory in C99, then optional in C11. Complex numbers are not
>> particularly hard to implement (once you have all the rest of floating
>> point support and <math.h>), and on the user side they are zero cost
>> if you don't use them.
>
> I had forgotten that C11 made complex numbers optional. I agree that it
> was an odd decision, as was making VLAs optional.
>
> Making a feature optional could be a good first step towards making it
> mandatory in a future edition of the standard. Making an existing
> mandatory feature optional makes less sense to me.
>

Could it have been pressure from a certain major compiler manufacturer
who has been extremely slow at implementing some C99 features, other
than those that were also part of C++ ? Perhaps they wanted to change
their reputation of being poor at C because they were far from C99
compliant, and they could now get C11 compliance with less effort.

Or maybe that's just a conspiracy theory :-)

On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> On 23/01/2023 21:15, Keith Thompson wrote:
> > David Brown <david...@hesbynett.no> writes:
> > [...]
> >> I also wonder why the committee choose to make complex numbers
> >> mandatory in C99, then optional in C11. Complex numbers are not
> >> particularly hard to implement (once you have all the rest of floating
> >> point support and <math.h>), and on the user side they are zero cost
> >> if you don't use them.
> >
> > I had forgotten that C11 made complex numbers optional. I agree that it
> > was an odd decision, as was making VLAs optional.
> >
> > Making a feature optional could be a good first step towards making it
> > mandatory in a future edition of the standard. Making an existing
> > mandatory feature optional makes less sense to me.
> >
> Could it have been pressure from a certain major compiler manufacturer
> who has been extremely slow at implementing some C99 features, other
> than those that were also part of C++ ? Perhaps they wanted to change
> their reputation of being poor at C because they were far from C99
> compliant, and they could now get C11 compliance with less effort.
>
>
> Or maybe that's just a conspiracy theory :-)

I'd guess, that's part of the reason.
The other part is desire to make 'C' maximally close to a subset of C++.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> BTW, I was wrong about one thing: Support for _Imaginary is optional
> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
> `#ifdef _Imaginary_I` can be used to detect whether an implementation
> supports imaginary types.

I don't see how you reach this conclusion. My reading of N1570 says
an implementation that defines __STDC_IEC_559_COMPLEX__ must have
imaginary types. Annex G is normative. It clearly states that an
implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
its specifications. Section G.2 says _Imaginary is a keyword, and
there are three imaginary types, float _Imaginary, double _Imaginary,
and long double _Imaginary. That statement (actually a combination of
two statements in the annex) is a specification, and so any designated
implementation must conform to it.

In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and
'_Imaginary_I' are defined if and only if the implementation supports
imaginary types, but I don't see that it gives any license to overrule
any other statement in the standard. Annex G is clear that there are
imaginary types, and the implementation must provide them. I don't
see any wiggle room at all. What is the reasoning behind what you
say above?

Michael S <already5chosen@yahoo.com> writes:

> On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
>> On 23/01/2023 21:15, Keith Thompson wrote:
>> > David Brown <david...@hesbynett.no> writes:
>> > [...]
>> >> I also wonder why the committee choose to make complex numbers
>> >> mandatory in C99, then optional in C11. Complex numbers are not
>> >> particularly hard to implement (once you have all the rest of floating
>> >> point support and <math.h>), and on the user side they are zero cost
>> >> if you don't use them.
>> >
>> > I had forgotten that C11 made complex numbers optional. I agree that it
>> > was an odd decision, as was making VLAs optional.
>> >
>> > Making a feature optional could be a good first step towards making it
>> > mandatory in a future edition of the standard. Making an existing
>> > mandatory feature optional makes less sense to me.
>> >
>> Could it have been pressure from a certain major compiler manufacturer
>> who has been extremely slow at implementing some C99 features, other
>> than those that were also part of C++ ? Perhaps they wanted to change
>> their reputation of being poor at C because they were far from C99
>> compliant, and they could now get C11 compliance with less effort.
>>
>> Or maybe that's just a conspiracy theory :-)
>
> I'd guess, that's part of the reason.
> The other part is desire to make 'C' maximally close to a subset of
> C++.

But then C++ has had complex numbers (alost from the get-go), so maybe
not!

--
Ben.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>> supports imaginary types.
>
> I don't see how you reach this conclusion. My reading of N1570 says
> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
> imaginary types. Annex G is normative. It clearly states that an
> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
> its specifications. Section G.2 says _Imaginary is a keyword, and
> there are three imaginary types, float _Imaginary, double _Imaginary,
> and long double _Imaginary. That statement (actually a combination of
> two statements in the annex) is a specification, and so any designated
> implementation must conform to it.

I believe you're correct, and I was wrong (the second time, not
the first). I honestly don't know how I reached the conclusion
that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
to support imaginary types. Most likely I read one document while
thinking it was a different one.

I apologize for the confusion.

> In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and
> '_Imaginary_I' are defined if and only if the implementation supports
> imaginary types, but I don't see that it gives any license to overrule
> any other statement in the standard. Annex G is clear that there are
> imaginary types, and the implementation must provide them. I don't
> see any wiggle room at all. What is the reasoning behind what you
> say above?

I now think that an implementation that defines __STDC_IEC_559_COMPLEX__
(which is optional) must support imaginary types as described in Annex G.
The N1570 draft, of the C11 standard, and of the N3054 draft of C23
are all consistent on this point.

Both gcc and clang define __STDC_IEC_559_COMPLEX__ but do not support
imaginary types (with command-line options to make them attempt to be
fully conforming). I find it surprising that they would both be
non-conforming in such a seemingly obvious way. The gcc 12.2.0 manual
doesn't even mention the _Imaginary keyword.

(Both complex and imaginary types are optional in C11. And a conforming
implementation could support both without supporting Annex G.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 1/23/23 19:37, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>>> supports imaginary types.
>>
>> I don't see how you reach this conclusion. My reading of N1570 says
>> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
>> imaginary types. Annex G is normative. It clearly states that an
>> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
>> its specifications. Section G.2 says _Imaginary is a keyword, and
>> there are three imaginary types, float _Imaginary, double _Imaginary,
>> and long double _Imaginary. That statement (actually a combination of
>> two statements in the annex) is a specification, and so any designated
>> implementation must conform to it.
>
> I believe you're correct, and I was wrong (the second time, not
> the first). I honestly don't know how I reached the conclusion
> that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
> to support imaginary types. Most likely I read one document while
> thinking it was a different one.

I think you were on the right track from the beginning.

"The macros imaginary and _Imaginary_I are defined if and only if the
implementation supports imaginary types." (7.3.1p5)

That pretty clearly indicates that support for imaginary types is
optional. It wouldn't be needed if imaginary types were guaranteed to be
supported if complex types are supported.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/23/23 19:37, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>>>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>>>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>>>> supports imaginary types.
>>>
>>> I don't see how you reach this conclusion. My reading of N1570 says
>>> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
>>> imaginary types. Annex G is normative. It clearly states that an
>>> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
>>> its specifications. Section G.2 says _Imaginary is a keyword, and
>>> there are three imaginary types, float _Imaginary, double _Imaginary,
>>> and long double _Imaginary. That statement (actually a combination of
>>> two statements in the annex) is a specification, and so any designated
>>> implementation must conform to it.
>>
>> I believe you're correct, and I was wrong (the second time, not
>> the first). I honestly don't know how I reached the conclusion
>> that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
>> to support imaginary types. Most likely I read one document while
>> thinking it was a different one.
>
> I think you were on the right track from the beginning.
>
> "The macros imaginary and _Imaginary_I are defined if and only if the
> implementation supports imaginary types." (7.3.1p5)
>
> That pretty clearly indicates that support for imaginary types is
> optional. It wouldn't be needed if imaginary types were guaranteed to be
> supported if complex types are supported.

N1570 6.2.5 (Types) mentions complex types but not imaginary types,
other than in a footnote that refers to Annex G (and that incorrectly
says it's informative, as it was in C99). That seems like an odd
omission.

N1570 7.3.1 (<complex.h>) makes it clear that imaginary types are
optional (and that the macro I expands to an expression of either
complex or imaginary type, which seems really odd).

6.10.8.1: An implementation may predefine __STDC_NO_COMPLEX__ to
indicate that it doesn't support complex types (new in C11; in C99
complex types were mandatory).

My conclusions:

Support for complex types is optional.

Support for imaginary types is optional.

(Support for imaginary types but not complex types is probably allowed,
but would be silly.)

An implementation may optionally predefine __STDC_IEC_559_COMPLEX__.
Any implementation that does so must support both complex and imaginary
types, and must do so as specified by Annex G.

Recent versions of gcc and clang both predefine __STDC_IEC_559_COMPLEX__,
but neither supports imaginary types (with command-line options that
should make them conform to C11). This makes them non-conforming. I
feel like I might be missing something here, because it *seems* like an
obvious non-conformance, and I don't see anything about it on gcc's
bugzilla.

An implementation *could* support complex types, or complex and
imaginary types, without conforming to Annex G, for example if the
target platform doesn't support IEEE floating-point.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote:
> Michael S <already...@yahoo.com> writes:
>
> > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> >> On 23/01/2023 21:15, Keith Thompson wrote:
> >> > David Brown <david...@hesbynett.no> writes:
> >> > [...]
> >> >> I also wonder why the committee choose to make complex numbers
> >> >> mandatory in C99, then optional in C11. Complex numbers are not
> >> >> particularly hard to implement (once you have all the rest of floating
> >> >> point support and <math.h>), and on the user side they are zero cost
> >> >> if you don't use them.
> >> >
> >> > I had forgotten that C11 made complex numbers optional. I agree that it
> >> > was an odd decision, as was making VLAs optional.
> >> >
> >> > Making a feature optional could be a good first step towards making it
> >> > mandatory in a future edition of the standard. Making an existing
> >> > mandatory feature optional makes less sense to me.
> >> >
> >> Could it have been pressure from a certain major compiler manufacturer
> >> who has been extremely slow at implementing some C99 features, other
> >> than those that were also part of C++ ? Perhaps they wanted to change
> >> their reputation of being poor at C because they were far from C99
> >> compliant, and they could now get C11 compliance with less effort.
> >>
> >> Or maybe that's just a conspiracy theory :-)
> >
> > I'd guess, that's part of the reason.
> > The other part is desire to make 'C' maximally close to a subset of
> > C++.
> But then C++ has had complex numbers (alost from the get-go), so maybe
> not!
>
> --
> Ben.

C++ complex numbers are part of template library rather than of base language.
C99 complex numbers and C++ complex number are not merely incompatible,
forcing them to co-exist in the same program is not easy.
And then, we have IPP (Intel Performance Primitives) complex types to make
things more interesting.

But my previous comment had smaller scope. All I wanted to say is that
committee likely wants to reduce the # of 'C' programs that are neither
legal C++ nor can be turned into legal C++ programs easily by adding few casts
[that will still keep the legal C programs].
C99 VLA and complex numbers are by far the biggest obstacles here.

wtorek, 24 stycznia 2023 o 11:46:23 UTC+1 Michael S napisał(a):
> On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote:
> > Michael S <already...@yahoo.com> writes:
> >
> > > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> > >> On 23/01/2023 21:15, Keith Thompson wrote:
> > >> > David Brown <david...@hesbynett.no> writes:
> > >> > [...]
> > >> >> I also wonder why the committee choose to make complex numbers
> > >> >> mandatory in C99, then optional in C11. Complex numbers are not
> > >> >> particularly hard to implement (once you have all the rest of floating
> > >> >> point support and <math.h>), and on the user side they are zero cost
> > >> >> if you don't use them.
> > >> >
> > >> > I had forgotten that C11 made complex numbers optional. I agree that it
> > >> > was an odd decision, as was making VLAs optional.
> > >> >
> > >> > Making a feature optional could be a good first step towards making it
> > >> > mandatory in a future edition of the standard. Making an existing
> > >> > mandatory feature optional makes less sense to me.
> > >> >
> > >> Could it have been pressure from a certain major compiler manufacturer
> > >> who has been extremely slow at implementing some C99 features, other
> > >> than those that were also part of C++ ? Perhaps they wanted to change
> > >> their reputation of being poor at C because they were far from C99
> > >> compliant, and they could now get C11 compliance with less effort.
> > >>
> > >> Or maybe that's just a conspiracy theory :-)
> > >
> > > I'd guess, that's part of the reason.
> > > The other part is desire to make 'C' maximally close to a subset of
> > > C++.
> > But then C++ has had complex numbers (alost from the get-go), so maybe
> > not!
> >
> > --
> > Ben.
> C++ complex numbers are part of template library rather than of base language.
> C99 complex numbers and C++ complex number are not merely incompatible,
> forcing them to co-exist in the same program is not easy.
> And then, we have IPP (Intel Performance Primitives) complex types to make
> things more interesting.
>
> But my previous comment had smaller scope. All I wanted to say is that
> committee likely wants to reduce the # of 'C' programs that are neither
> legal C++ nor can be turned into legal C++ programs easily by adding few casts
> [that will still keep the legal C programs].
> C99 VLA and complex numbers are by far the biggest obstacles here.

complex numbers should be implemented but not so much in c or c++ but on the cpu/assembly level

it is bcouse the basic oparation of complex number it is x,y <-> fi, R
(which uses atan2 and sqr cos and sin) is very basic and needed

i also think that cpu should have precision for trigonometry to be set up
becouse for many calculations for example when you got some x,y point
and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess

there is though a problem how to expres it in language also

wtorek, 24 stycznia 2023 o 13:18:13 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 11:46:23 UTC+1 Michael S napisał(a):
> > On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote:
> > > Michael S <already...@yahoo.com> writes:
> > >
> > > > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> > > >> On 23/01/2023 21:15, Keith Thompson wrote:
> > > >> > David Brown <david...@hesbynett.no> writes:
> > > >> > [...]
> > > >> >> I also wonder why the committee choose to make complex numbers
> > > >> >> mandatory in C99, then optional in C11. Complex numbers are not
> > > >> >> particularly hard to implement (once you have all the rest of floating
> > > >> >> point support and <math.h>), and on the user side they are zero cost
> > > >> >> if you don't use them.
> > > >> >
> > > >> > I had forgotten that C11 made complex numbers optional. I agree that it
> > > >> > was an odd decision, as was making VLAs optional.
> > > >> >
> > > >> > Making a feature optional could be a good first step towards making it
> > > >> > mandatory in a future edition of the standard. Making an existing
> > > >> > mandatory feature optional makes less sense to me.
> > > >> >
> > > >> Could it have been pressure from a certain major compiler manufacturer
> > > >> who has been extremely slow at implementing some C99 features, other
> > > >> than those that were also part of C++ ? Perhaps they wanted to change
> > > >> their reputation of being poor at C because they were far from C99
> > > >> compliant, and they could now get C11 compliance with less effort.
> > > >>
> > > >> Or maybe that's just a conspiracy theory :-)
> > > >
> > > > I'd guess, that's part of the reason.
> > > > The other part is desire to make 'C' maximally close to a subset of
> > > > C++.
> > > But then C++ has had complex numbers (alost from the get-go), so maybe
> > > not!
> > >
> > > --
> > > Ben.
> > C++ complex numbers are part of template library rather than of base language.
> > C99 complex numbers and C++ complex number are not merely incompatible,
> > forcing them to co-exist in the same program is not easy.
> > And then, we have IPP (Intel Performance Primitives) complex types to make
> > things more interesting.
> >
> > But my previous comment had smaller scope. All I wanted to say is that
> > committee likely wants to reduce the # of 'C' programs that are neither
> > legal C++ nor can be turned into legal C++ programs easily by adding few casts
> > [that will still keep the legal C programs].
> > C99 VLA and complex numbers are by far the biggest obstacles here.
> complex numbers should be implemented but not so much in c or c++ but on the cpu/assembly level
>
> it is bcouse the basic oparation of complex number it is x,y <-> fi, R
> (which uses atan2 and sqr cos and sin) is very basic and needed
>
> i also think that cpu should have precision for trigonometry to be set up
> becouse for many calculations for example when you got some x,y point
> and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess
>
> there is though a problem how to expres it in language also

main problem is how to expres it in one line

i mean if you got o is a complex how to writa and read .x .y at once

p = {1,2}

{a,b}=p;

could be theoretycally used but im not sure its the best (though its also not the worst)

note if so this also rather mean that more natural function call is foo{1,2,3}
than foo(1,2,3) but round bersion looks better so maybe it suggest that
p=(1,2); (a,b)=p can be used (and maybe even p(1,2) and(a,b)p for short

its even kinda funny bcouse f(1,2,3,4) is a call with pasing and (a,b,c,d)f is a call with reting (returning) looks quite ok... [and this is stage idea how to do this complex call and et expressions when one is allowed to return more than one value, first time i seen that]

not sayin this syntax is the best as | looks tremendously good as separator,
but there it need proper decision when to use it and when not

note there is general separator that separates things in c (may be consecutive
function calls) and special separator that separates elemend of a vector/record/structure (and this separator has somewhat meaning of a gluer not separator, and maybe it would be good to use , more like separator and | more like gluer, im not sure yet though

wtorek, 24 stycznia 2023 o 13:46:03 UTC+1 fir napisał(a):

> > it is bcouse the basic oparation of complex number it is x,y <-> fi, R
> > (which uses atan2 and sqr cos and sin) is very basic and needed
> >
> > i also think that cpu should have precision for trigonometry to be set up
> > becouse for many calculations for example when you got some x,y point
> > and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess
> >
> > there is though a problem how to expres it in language also
> main problem is how to expres it in one line
>
> i mean if you got o is a complex how to writa and read .x .y at once
>
> p = {1,2}
>
> {a,b}=p;
>
> could be theoretycally used but im not sure its the best (though its also not the worst)
>
> note if so this also rather mean that more natural function call is foo{1,2,3}
> than foo(1,2,3) but round bersion looks better so maybe it suggest that
> p=(1,2); (a,b)=p can be used (and maybe even p(1,2) and(a,b)p for short
>
> its even kinda funny bcouse f(1,2,3,4) is a call with pasing and (a,b,c,d)f is a call with reting (returning) looks quite ok... [and this is stage idea how to do this complex call and et expressions when one is allowed to return more than one value, first time i seen that]
>
> not sayin this syntax is the best as | looks tremendously good as separator,
> but there it need proper decision when to use it and when not
>
> note there is general separator that separates things in c (may be consecutive
> function calls) and special separator that separates elemend of a vector/record/structure (and this separator has somewhat meaning of a gluer not separator, and maybe it would be good to use , more like separator and | more like gluer, im not sure yet though

this obviously looks kinda good and as i said probbaly resolves some of my syntax problems

interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo

Michael S <already5chosen@yahoo.com> writes:

> On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote:
>> Michael S <already...@yahoo.com> writes:
>>
>> > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
>> >> On 23/01/2023 21:15, Keith Thompson wrote:
>> >> > David Brown <david...@hesbynett.no> writes:
>> >> > [...]
>> >> >> I also wonder why the committee choose to make complex numbers
>> >> >> mandatory in C99, then optional in C11. Complex numbers are not
>> >> >> particularly hard to implement (once you have all the rest of floating
>> >> >> point support and <math.h>), and on the user side they are zero cost
>> >> >> if you don't use them.
>> >> >
>> >> > I had forgotten that C11 made complex numbers optional. I agree that it
>> >> > was an odd decision, as was making VLAs optional.
>> >> >
>> >> > Making a feature optional could be a good first step towards making it
>> >> > mandatory in a future edition of the standard. Making an existing
>> >> > mandatory feature optional makes less sense to me.
>> >> >
>> >> Could it have been pressure from a certain major compiler manufacturer
>> >> who has been extremely slow at implementing some C99 features, other
>> >> than those that were also part of C++ ? Perhaps they wanted to change
>> >> their reputation of being poor at C because they were far from C99
>> >> compliant, and they could now get C11 compliance with less effort.
>> >>
>> >> Or maybe that's just a conspiracy theory :-)
>> >
>> > I'd guess, that's part of the reason.
>> > The other part is desire to make 'C' maximally close to a subset of
>> > C++.
>> But then C++ has had complex numbers (alost from the get-go), so maybe
>> not!
>
> C++ complex numbers are part of template library rather than of base language.
> C99 complex numbers and C++ complex number are not merely incompatible,
> forcing them to co-exist in the same program is not easy.
> And then, we have IPP (Intel Performance Primitives) complex types to make
> things more interesting.
>
> But my previous comment had smaller scope. All I wanted to say is that
> committee likely wants to reduce the # of 'C' programs that are neither
> legal C++ nor can be turned into legal C++ programs easily by adding few casts
> [that will still keep the legal C programs].
> C99 VLA and complex numbers are by far the biggest obstacles here.

OK, I see where you are going with this. You think that minimal
adjustment is the aim. I was thinking that some class of programs using
C's complex numbers could be made valid C++ with a fee macros and an #if
or two, but it's been years since I wrote any such code and, anyway, you
are suggesting a much narrower concept of "subset".

By the way, are you basing this suggestion on some inside information (a
paper, a private conversation...) or is it speculative?

--
Ben.

wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
>
> interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo

some simple confusion i got was
what that should be

a, b=c, d

or what that should be

a b c

doeas todays conclusion say something on that? maybe..

the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)

a b c

in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))

a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right

maybe its becouse it conforms to

p = {1,2}

which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not

wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> >
> > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> some simple confusion i got was
> what that should be
>
> a, b=c, d
>
> or what that should be
>
> a b c
>
> doeas todays conclusion say something on that? maybe..
>
> the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
>
> a b c
>
> in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
>
> a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
>
> maybe its becouse it conforms to
>
> p = {1,2}
>
> which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not

hovewer some could say this yeild to some practical problem,
becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line

where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like

void SetupCloud
{
ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
1:200: cloud_x.add(rand2 200 1900),
cloud_y.add(rand2 2200 3500)
cloud_z.add(rand2 0 1300)
cloud_r.add(rand2 10 30)
cloud_color.add(RandColor 0 255 0 255 0 255) ;
}

so quite different to what i say

but i dont wand now to think on that yet

wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > >
> > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > some simple confusion i got was
> > what that should be
> >
> > a, b=c, d
> >
> > or what that should be
> >
> > a b c
> >
> > doeas todays conclusion say something on that? maybe..
> >
> > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> >
> > a b c
> >
> > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> >
> > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> >
> > maybe its becouse it conforms to
> >
> > p = {1,2}
> >
> > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> hovewer some could say this yeild to some practical problem,
> becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
>
> where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
>
> void SetupCloud
> {
> ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> 1:200: cloud_x.add(rand2 200 1900),
> cloud_y.add(rand2 2200 3500)
> cloud_z.add(rand2 0 1300)
> cloud_r.add(rand2 10 30)
> cloud_color.add(RandColor 0 255 0 255 0 255) ;
> }
>
> so quite different to what i say
>
> but i dont wand now to think on that yet

well overally this is maybe not much important yet becouse this is
matter of prioritizing operators (of calling structurization and separation)
underlying semantic behaviour seem to eb mostly done (probably) and
this seem most important

i probbaly need to do some experiments, it seem dor example that
if for example make rule that caling needs parenthesis and
no caling without parentesis can be done then sole space and
parenthesis may done a lot of structurisation and calling
itsef (by calling i also mean assigning bcouse = is not needed
so a lot of calling assigning and structurisation may be done
by pure spaces and parenthesis it seems so..then comma bay be add
as rough separator

wtorek, 24 stycznia 2023 o 14:53:41 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > > >
> > > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > > some simple confusion i got was
> > > what that should be
> > >
> > > a, b=c, d
> > >
> > > or what that should be
> > >
> > > a b c
> > >
> > > doeas todays conclusion say something on that? maybe..
> > >
> > > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> > >
> > > a b c
> > >
> > > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> > >
> > > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> > >
> > > maybe its becouse it conforms to
> > >
> > > p = {1,2}
> > >
> > > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> > hovewer some could say this yeild to some practical problem,
> > becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
> >
> > where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
> >
> > void SetupCloud
> > {
> > ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> > 1:200: cloud_x.add(rand2 200 1900),
> > cloud_y.add(rand2 2200 3500)
> > cloud_z.add(rand2 0 1300)
> > cloud_r.add(rand2 10 30)
> > cloud_color.add(RandColor 0 255 0 255 0 255) ;
> > }
> >
> > so quite different to what i say
> >
> > but i dont wand now to think on that yet
> well overally this is maybe not much important yet becouse this is
> matter of prioritizing operators (of calling structurization and separation)
> underlying semantic behaviour seem to eb mostly done (probably) and
> this seem most important
>
> i probbaly need to do some experiments, it seem dor example that
> if for example make rule that caling needs parenthesis and
> no caling without parentesis can be done then sole space and
> parenthesis may done a lot of structurisation and calling
> itsef (by calling i also mean assigning bcouse = is not needed
> so a lot of calling assigning and structurisation may be done
> by pure spaces and parenthesis it seems so..then comma bay be add
> as rough separator

it is damn sad to say

a b c

cant be a calls (call-chain) and you must write a(b(c))

but if you say it can be calls then f(a b c) cant ba a call on vector becouse a b c cant ba a vector and it must be written f(a,b,c) (or f a,b,c as i was writing)

from those two decisions (CAN and CANT ) CAN seem to be better probably
(though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better
but it needs investigation (CAN option is imo more clasical)

wtorek, 24 stycznia 2023 o 15:20:56 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:53:41 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> > > wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > > > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > > > >
> > > > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > > > some simple confusion i got was
> > > > what that should be
> > > >
> > > > a, b=c, d
> > > >
> > > > or what that should be
> > > >
> > > > a b c
> > > >
> > > > doeas todays conclusion say something on that? maybe..
> > > >
> > > > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> > > >
> > > > a b c
> > > >
> > > > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> > > >
> > > > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> > > >
> > > > maybe its becouse it conforms to
> > > >
> > > > p = {1,2}
> > > >
> > > > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > > > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> > > hovewer some could say this yeild to some practical problem,
> > > becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
> > >
> > > where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
> > >
> > > void SetupCloud
> > > {
> > > ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> > > 1:200: cloud_x.add(rand2 200 1900),
> > > cloud_y.add(rand2 2200 3500)
> > > cloud_z.add(rand2 0 1300)
> > > cloud_r.add(rand2 10 30)
> > > cloud_color.add(RandColor 0 255 0 255 0 255) ;
> > > }
> > >
> > > so quite different to what i say
> > >
> > > but i dont wand now to think on that yet
> > well overally this is maybe not much important yet becouse this is
> > matter of prioritizing operators (of calling structurization and separation)
> > underlying semantic behaviour seem to eb mostly done (probably) and
> > this seem most important
> >
> > i probbaly need to do some experiments, it seem dor example that
> > if for example make rule that caling needs parenthesis and
> > no caling without parentesis can be done then sole space and
> > parenthesis may done a lot of structurisation and calling
> > itsef (by calling i also mean assigning bcouse = is not needed
> > so a lot of calling assigning and structurisation may be done
> > by pure spaces and parenthesis it seems so..then comma bay be add
> > as rough separator
> it is damn sad to say
>
> a b c
>
> cant be a calls (call-chain) and you must write a(b(c))
>
> but if you say it can be calls then f(a b c) cant ba a call on vector becouse a b c cant ba a vector and it must be written f(a,b,c) (or f a,b,c as i was writing)
>
> from those two decisions (CAN and CANT ) CAN seem to be better probably
> (though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better
> but it needs investigation (CAN option is imo more clasical)

well in fact the option that a b,c may be treated as (a b), c may be seen as THIRD option so maybe in fact i should reconsider that too, but im a littel tired recently (feels like i cant feel the upper part of my brain, but maybe i should rest)

the third option allows a b c (as CAN version do) it also gives rough separator (as CANT version gives) it changes the meaning of a,b=3,c but maybe its not such bad, i cant compregend it fully now but probably teh way of getting to some conclusion is to slowly compare those 3 syntax scenarios then yet see if some additional will not do appear

wtorek, 24 stycznia 2023 o 15:56:32 UTC+1 fir napisał(a):
> >
> > from those two decisions (CAN and CANT ) CAN seem to be better probably
> > (though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better
> > but it needs investigation (CAN option is imo more clasical)
> well in fact the option that a b,c may be treated as (a b), c may be seen as THIRD option so maybe in fact i should reconsider that too, but im a littel tired recently (feels like i cant feel the upper part of my brain, but maybe i should rest)
>
> the third option allows a b c (as CAN version do) it also gives rough separator (as CANT version gives) it changes the meaning of a,b=3,c but maybe its not such bad, i cant compregend it fully now but probably teh way of getting to some conclusion is to slowly compare those 3 syntax scenarios then yet see if some additional will not do appear

to sum examples

a b c
a b,c
a,b c,d

CANT: space means structurizer, comma means separator, () needed for call/assignment

CAN: space means call, comma means structurizer

THIRD: space means call, comma means separator and structurizer (if in parenthesis)

riht now i would consider CAN and THIRD as usablem CAN is good
but someone needs additional separator, THIRD gives separator
but it needs parenthesis in calls that gabe more than 1 argument
*which is maybe standalbe)

so for now maybe the third is most usable

On Tuesday, January 24, 2023 at 2:56:59 PM UTC+2, Ben Bacarisse wrote:
> By the way, are you basing this suggestion on some inside information (a
> paper, a private conversation...) or is it speculative?
>
> --
> Ben.

the later

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>>> supports imaginary types.
>>
>> I don't see how you reach this conclusion. My reading of N1570 says
>> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
>> imaginary types. Annex G is normative. It clearly states that an
>> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
>> its specifications. Section G.2 says _Imaginary is a keyword, and
>> there are three imaginary types, float _Imaginary, double _Imaginary,
>> and long double _Imaginary. That statement (actually a combination of
>> two statements in the annex) is a specification, and so any designated
>> implementation must conform to it.
>
> I believe you're correct, and I was wrong (the second time, not
> the first). I honestly don't know how I reached the conclusion
> that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
> to support imaginary types. Most likely I read one document while
> thinking it was a different one.
>
> I apologize for the confusion.

No apology needed.

>> In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and
>> '_Imaginary_I' are defined if and only if the implementation supports
>> imaginary types, but I don't see that it gives any license to overrule
>> any other statement in the standard. Annex G is clear that there are
>> imaginary types, and the implementation must provide them. I don't
>> see any wiggle room at all. What is the reasoning behind what you
>> say above?
>
> I now think that an implementation that defines __STDC_IEC_559_COMPLEX__
> (which is optional) must support imaginary types as described in Annex G.
> The N1570 draft, of the C11 standard, and of the N3054 draft of C23
> are all consistent on this point.
>
> Both gcc and clang define __STDC_IEC_559_COMPLEX__ but do not support
> imaginary types (with command-line options to make them attempt to be
> fully conforming). I find it surprising that they would both be
> non-conforming in such a seemingly obvious way. The gcc 12.2.0 manual
> doesn't even mention the _Imaginary keyword.

What may have happened is that gcc implemented complex types
around the time of C99, when complex types were required but
Annex G was merely informative (and the last sentence of G.1
says "should conform" rather than "shall conform" as it does
in C11). As far as C99 is concerned, gcc and clang are both
conforming.

Then, when C11 came along, no one noticed the switch in status of
Annex G, and since relatively few people care about imaginary
types, no one noticed that their absence violated the rules in
the new standard. It may be the case that there are other parts
of Annex G that either gcc or clang do not satisfy, perhaps
because no one has pointed out the (possible) deficiencies.

It would be nice if some energetic person would enter a bug
report on the gcc bug list site, regarding the missing imaginary
types. I have put in gcc bug reports in the past but don't have
as much time for that now.