Re: Add corollary extension
On Thu, Jun 28, 2012 at 12:39:16PM -0700, Rick Hodgin wrote: > I've thought more about the syntax, and I see this making more sense: > bool isSystemOpen[!isSystemClosed]; You've just declared an array of bool, whose size is the expression !isSystemClosed. As developers have already showed you how to achieve what you want in the existing language, you should define an inv_bool class, then write inv_bool isSystemOpen(isSystemClosed); and use the feature to your heart's content. There's a very high bar to accepting a language extension, because developers need to know, to "draft standard" level of detail, how that feature interacts with existing language features, and you can't change the meaning of valid code. Furthermore, the vast engineering effort isn't worth doing if users can achieve the same thing in the standard language, perhaps with slightly different syntax. The previous proposal was for a "self" keyword. But #define self (*this) and you're done.
Re: Add corollary extension
On 06/28/2012 08:39 PM, Rick Hodgin wrote:
>> Why do you want to bother with a non-standard,
>> unportable extension instead of just writing:
>>
>> inline bool isSystemClosed()
>> { return !isSystemOpen; }
>>
>> Which is simple, conventional, easy to understand
>> and portable.
>>
>> Or in C++ just define a suitable type, instead of
>> needing changes to the core language:
>>
>> struct inv_bool {
>> bool& b;
>> operator bool() const { return !b; }
>> };
>>
>> inv_bool isSystemClosed = { isSystemOpen };
or, better:
inv_bool isSystemClosed(isSystemOpen);
>
> There are certain fundamentals in data processing. The inverse bool
> is one of them. Why not be able to reference it more naturally in
> code utilizing something the compiler already knows about and can
> wield effortlessly?
>
> I've thought more about the syntax, and I see this making more sense:
> bool isSystemOpen[!isSystemClosed];
But why is this new syntax better than
inv_bool isSystemClosed(isSystemOpen);
Andrew.
Re: Add corollary extension
In a boolean variable, there are two fundamental ways to examine: as it is, or !(as it is). Using the same memory location to access those two base / fundamental extents of its very nature, while new in concept to C/C++ hackers, is not new in any degree of concept. Five year olds use this in speech everyday. The only thing I propose is to give boolean variables their full roundness of use in the C and C++ languages. As they are today, half of their abilities are natively exposed to the developer, the other half are suppressed and hidden behind reverse logic, yielding more icky code than need be. This is my last comment on the post. It's just that I just believe that anything worth doing is worth doing rightly, and completely. Not having native inverse bool support seems incomplete to me. Best regards, Rick C. Hodgin Original Message From: James Dennett Sent: Thu, Jun 28, 2012 06:24 PM To: Rick C. Hodgin CC: Jonathan Wakely ; gcc Subject: Re: Add corollary extension >On Thu, Jun 28, 2012 at 3:08 PM, Rick C. Hodgin wrote: >> How would you handle: >> >> isSystemClosed = true; > >A good clean error message is ideal, and should be easy. (A proxy >object such as inv_bool can do this easily enough, but it's still >going to hurt readability.) > >> You're getting into nasty looking/non-obvious code to use language-existing >> features for an ability that 1) is fundamental to software and 2) should >> have native support without kludges. > >No, the ability to have two different variables with different >semantics but shared backing store is not fundamental, it's rather a >violation of the law of least surprise. > >(I'm not buying that lambdas are "nasty looking" or "non-obvious" for >C++ users. They're a fundamental part of the language.) > >I understand that you really like your notation, and think that it's a >clear win. I don't think you'll have luck persuading compiler writers >or language committees, but maybe you'll prove me wrong. > >-- James
Re: Add corollary extension
On Thu, Jun 28, 2012 at 3:08 PM, Rick C. Hodgin wrote: > How would you handle: > > isSystemClosed = true; A good clean error message is ideal, and should be easy. (A proxy object such as inv_bool can do this easily enough, but it's still going to hurt readability.) > You're getting into nasty looking/non-obvious code to use language-existing > features for an ability that 1) is fundamental to software and 2) should have > native support without kludges. No, the ability to have two different variables with different semantics but shared backing store is not fundamental, it's rather a violation of the law of least surprise. (I'm not buying that lambdas are "nasty looking" or "non-obvious" for C++ users. They're a fundamental part of the language.) I understand that you really like your notation, and think that it's a clear win. I don't think you'll have luck persuading compiler writers or language committees, but maybe you'll prove me wrong. -- James
Re: Add corollary extension
On Thu, 2012-06-28 at 18:08 -0400, Rick C. Hodgin wrote:
> How would you handle:
>
> isSystemClosed = true;
By adding one line to inv_bool
struct inv_bool {
bool& b;
operator bool() const { return !b; }
inv_bool& operator = (bool _b) { b = !_b; return *this; }
};
Cheers,
Oleg
Re: Add corollary extension
How would you handle:
isSystemClosed = true;
You're getting into nasty looking/non-obvious code to use language-existing
features for an ability that 1) is fundamental to software and 2) should have
native support without kludges.
Many CPUs even support the write-back NOT of a flag condition natively. x86 has
the SETcc instructions, for example, which are native to this concept. ARM has
predicates. It is already there at the CPU level.
Best regards,
Rick C. Hodgin
Original Message
From: James Dennett
Sent: Thu, Jun 28, 2012 04:14 PM
To: Rick Hodgin
CC: Jonathan Wakely ; gcc
Subject: Re: Add corollary extension
>On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin wrote:
>>> Why do you want to bother with a non-standard,
>>> unportable extension instead of just writing:
>>>
>>> inline bool isSystemClosed()
>>> { return !isSystemOpen; }
>>>
>>> Which is simple, conventional, easy to understand
>>> and portable.
>>>
>>> Or in C++ just define a suitable type, instead of
>>> needing changes to the core language:
>>>
>>> struct inv_bool {
>>> bool& b;
>>> operator bool() const { return !b; }
>>> };
>>>
>>> inv_bool isSystemClosed = { isSystemOpen };
>>
>> There are certain fundamentals in data processing. The inverse bool is one
>> of them. Why not be able to reference it more naturally in code utilizing
>> something the compiler already knows about and can wield effortlessly?
>>
>> I've thought more about the syntax, and I see this making more sense:
>> bool isSystemOpen[!isSystemClosed];
>>
>> As the inverse bool relationship is fundamental in software, I hope this
>> will become a C/C++ standard.
>
>I really can't imagine that happening. As the logical not operation
>is fundamental, we already have notation for it. Why would we add the
>complexity of something that looks like a variable but acts like a
>function? In C++ you can already write
> auto isSystemOpen = [&isSystemClosed] { return !isSystemClosed; };
>and then use isSystemOpen(), without doing violence to variable
>notation. You can obscure that behind a macro in your own code if you
>wish, as in
> #define OPPOSITE(realVariable) (&realVariable] { return !realVariable; })
> auto isSystemOpen = OPPOSITE(isSystemClosed);
>but wanting to make something that's a function look like a variable
>isn't likely to get much traction in either language.
>
>-- James
Re: Add corollary extension
On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin wrote:
>> Why do you want to bother with a non-standard,
>> unportable extension instead of just writing:
>>
>> inline bool isSystemClosed()
>> { return !isSystemOpen; }
>>
>> Which is simple, conventional, easy to understand
>> and portable.
>>
>> Or in C++ just define a suitable type, instead of
>> needing changes to the core language:
>>
>> struct inv_bool {
>> bool& b;
>> operator bool() const { return !b; }
>> };
>>
>> inv_bool isSystemClosed = { isSystemOpen };
>
> There are certain fundamentals in data processing. The inverse bool is one
> of them. Why not be able to reference it more naturally in code utilizing
> something the compiler already knows about and can wield effortlessly?
>
> I've thought more about the syntax, and I see this making more sense:
> bool isSystemOpen[!isSystemClosed];
>
> As the inverse bool relationship is fundamental in software, I hope this will
> become a C/C++ standard.
I really can't imagine that happening. As the logical not operation
is fundamental, we already have notation for it. Why would we add the
complexity of something that looks like a variable but acts like a
function? In C++ you can already write
auto isSystemOpen = [&isSystemClosed] { return !isSystemClosed; };
and then use isSystemOpen(), without doing violence to variable
notation. You can obscure that behind a macro in your own code if you
wish, as in
#define OPPOSITE(realVariable) (&realVariable] { return !realVariable; })
auto isSystemOpen = OPPOSITE(isSystemClosed);
but wanting to make something that's a function look like a variable
isn't likely to get much traction in either language.
-- James
Re: Add corollary extension
> Why do you want to bother with a non-standard,
> unportable extension instead of just writing:
>
> inline bool isSystemClosed()
> { return !isSystemOpen; }
>
> Which is simple, conventional, easy to understand
> and portable.
>
> Or in C++ just define a suitable type, instead of
> needing changes to the core language:
>
> struct inv_bool {
> bool& b;
> operator bool() const { return !b; }
> };
>
> inv_bool isSystemClosed = { isSystemOpen };
There are certain fundamentals in data processing. The inverse bool is one of
them. Why not be able to reference it more naturally in code utilizing
something the compiler already knows about and can wield effortlessly?
I've thought more about the syntax, and I see this making more sense:
bool isSystemOpen[!isSystemClosed];
As the inverse bool relationship is fundamental in software, I hope this will
become a C/C++ standard.
Best regards,
Rick C. Hodgin
Re: Add corollary extension
On 28 June 2012 17:00, Rick Hodgin wrote:
> I'd like to add an inverse definition to an existing BOOL/bool type, one
> which the compiler is natively aware of.
>
> Example:
> bool isSystemOpen;
>
> I can reference this in the manner in which it's defined:
> if (isSystemOpen)
> if (!isSystemOpen)
>
> However, there are times when it's more desirable to reference it in the
> opposite manner as it makes more logical sense to humans.
>
> The compiler is aware of the boolean nature of that variable, so I would like
> to be able to create a new form which is aware of the inverse boolean
> condition natively.
>
> Example syntax:
> bool isSystemOpen[.isSystemClosed.];
>
> This new syntax creates one physical variable, and two logical ways to
> reference the same variable in memory, but always tests for the inverse
> condition correctly, such as:
> if (isSystemClosed)
>
> Which would be the same logically as:
> if (!isSystemOpen)
>
> Any ideas on how to best / easily implement this? :-) I had the idea of just
> writing a pre-processor to look for those references and swap them out with
> the opposite condition. But it seems GCC should be able to do this natively.
Why do you want to bother with a non-standard, unportable extension
instead of just writing:
inline bool isSystemClosed()
{ return !isSystemOpen; }
Which is simple, conventional, easy to understand and portable.
Or in C++ just define a suitable type, instead of needing changes to
the core language:
struct inv_bool {
bool& b;
operator bool() const { return !b; }
};
inv_bool isSystemClosed = { isSystemOpen };
Add corollary extension
I'd like to add an inverse definition to an existing BOOL/bool type, one which the compiler is natively aware of. Example: bool isSystemOpen; I can reference this in the manner in which it's defined: if (isSystemOpen) if (!isSystemOpen) However, there are times when it's more desirable to reference it in the opposite manner as it makes more logical sense to humans. The compiler is aware of the boolean nature of that variable, so I would like to be able to create a new form which is aware of the inverse boolean condition natively. Example syntax: bool isSystemOpen[.isSystemClosed.]; This new syntax creates one physical variable, and two logical ways to reference the same variable in memory, but always tests for the inverse condition correctly, such as: if (isSystemClosed) Which would be the same logically as: if (!isSystemOpen) Any ideas on how to best / easily implement this? :-) I had the idea of just writing a pre-processor to look for those references and swap them out with the opposite condition. But it seems GCC should be able to do this natively. Thanks. Best regards, Rick C. Hodgin
