Add corollary extension

Add corollary extension

[Rick Hodgin]

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

Re: Add corollary extension

[Jonathan Wakely]

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 };

Re: Add corollary extension

[Rick Hodgin]

> 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

[James Dennett]

On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin <foxmuldrster@yahoo.com> 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

[Andrew Haley]

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

[Joe Buck]

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

[Rick C. Hodgin]

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 <james.dennett@gmail.com>
 Sent: Thu, Jun 28, 2012 06:24 PM
 To: Rick C. Hodgin <foxmuldrster@yahoo.com>
 CC: Jonathan Wakely <jwakely.gcc@gmail.com>; gcc <gcc@gcc.gnu.org>
 Subject: Re: Add corollary extension

>On Thu, Jun 28, 2012 at 3:08 PM, Rick C. Hodgin <foxmuldrster@yahoo.com> 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

[James Dennett]

On Thu, Jun 28, 2012 at 3:08 PM, Rick C. Hodgin <foxmuldrster@yahoo.com> 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

[Oleg Endo]

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

[Rick C. Hodgin]

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 <james.dennett@gmail.com>
 Sent: Thu, Jun 28, 2012 04:14 PM
 To: Rick Hodgin <foxmuldrster@yahoo.com>
 CC: Jonathan Wakely <jwakely.gcc@gmail.com>; gcc <gcc@gcc.gnu.org>
 Subject: Re: Add corollary extension

>On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin <foxmuldrster@yahoo.com> 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