Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #91637 > unrolled thread

Synthetic 'unless' keyword

Back to article view | Back to comp.lang.c

Contents

  Synthetic 'unless' keyword jt@toerring.de (Jens Thoms Toerring) - 2016-08-04 09:44 +0000
    Re: Synthetic 'unless' keyword David Brown <david.brown@hesbynett.no> - 2016-08-04 12:21 +0200
    Re: Synthetic 'unless' keyword Mark Storkamp <mstorkamp@yahoo.com> - 2016-08-04 07:01 -0500
      Re: Synthetic 'unless' keyword bert <bert.hutchings@btinternet.com> - 2016-08-04 05:42 -0700
      Re: Synthetic 'unless' keyword Keith Thompson <kst-u@mib.org> - 2016-08-04 08:45 -0700
        Re: Synthetic 'unless' keyword Philip Lantz <prl@canterey.us> - 2016-08-04 21:55 -0700
        Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-05 10:08 +0100
      Re: Synthetic 'unless' keyword Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 01:17 -0700
        Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-05 10:01 +0100
          Re: Synthetic 'unless' keyword Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 04:34 -0700
        Re: Synthetic 'unless' keyword Mark Storkamp <mstorkamp@yahoo.com> - 2016-08-05 09:37 -0500
          Re: Synthetic 'unless' keyword Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 02:28 -0700
    Re: Synthetic 'unless' keyword jt@toerring.de (Jens Thoms Toerring) - 2016-08-04 13:38 +0000
    Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-04 15:04 +0100
    Re: Synthetic 'unless' keyword mark.bluemel@gmail.com - 2016-08-04 07:06 -0700
    Re: Synthetic 'unless' keyword Keith Thompson <kst-u@mib.org> - 2016-08-04 08:52 -0700
      Re: Synthetic 'unless' keyword supercat@casperkitty.com - 2016-08-04 09:45 -0700
        Re: Synthetic 'unless' keyword Keith Thompson <kst-u@mib.org> - 2016-08-04 10:23 -0700
          Re: Synthetic 'unless' keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 19:39 +0100
            Re: Synthetic 'unless' keyword supercat@casperkitty.com - 2016-08-04 12:02 -0700
              Re: Synthetic 'unless' keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:33 +0100
              Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-04 20:42 +0100
                Re: Synthetic 'unless' keyword David Brown <david.brown@hesbynett.no> - 2016-08-05 13:14 +0200
                  Re: Synthetic 'unless' keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 12:41 +0100
      Re: Synthetic 'unless' keyword mark.bluemel@gmail.com - 2016-08-05 00:53 -0700
    Re: Synthetic 'unless' keyword Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 16:43 -0400
      Re: Synthetic 'unless' keyword David Brown <david.brown@hesbynett.no> - 2016-08-05 13:16 +0200
    Re: Synthetic 'unless' keyword jt@toerring.de (Jens Thoms Toerring) - 2016-08-04 23:16 +0000
      Re: Synthetic 'unless' keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 00:35 +0100
      Re: Synthetic 'unless' keyword Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 20:13 -0700
      Re: Synthetic 'unless' keyword Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 04:57 -0700
        Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-05 13:15 +0100
          Re: Synthetic 'unless' keyword Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-18 08:11 -0700
            Re: Synthetic 'unless' keyword BartC <bc@freeuk.com> - 2016-08-18 16:36 +0100
              Re: Synthetic 'unless' keyword supercat@casperkitty.com - 2016-08-18 10:20 -0700
    Re: Synthetic 'unless' keyword Paul N <gw7rib@aol.com> - 2016-08-07 12:56 -0700

Page 1 of 2  [1] 2  Next page →

#91637 — Synthetic 'unless' keyword

Hi,

  everyone uses 'if' probably hundreds of times a day.
But in some situations I'd feel that being able to use
'unless' instead, as in the trivial example

  unless (argc > 1) {
      fprintf(stderr, "Missing argument(s)\n");
      return EXIT_FAILURE;
  }

might contribute to the readability of the code. Now,
'unless' isn't a C keyword (as it is in some other
languages, e.g. Perl) but it seems easy to use a
define like this

#define unless(expr) if (!(expr))

What possibly could go wrong (except that 'unless' may
be used as a variable name somewhere and that editors
with syntax highlighting won't recognize it)? Or would
it be to "alien" to most C programmers?

                   Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [next] | [standalone]

#91638

On 04/08/16 11:44, Jens Thoms Toerring wrote:
> Hi,
> 
>   everyone uses 'if' probably hundreds of times a day.
> But in some situations I'd feel that being able to use
> 'unless' instead, as in the trivial example
> 
>   unless (argc > 1) {
>       fprintf(stderr, "Missing argument(s)\n");
>       return EXIT_FAILURE;
>   }
> 
> might contribute to the readability of the code. Now,
> 'unless' isn't a C keyword (as it is in some other
> languages, e.g. Perl) but it seems easy to use a
> define like this
> 
> #define unless(expr) if (!(expr))
> 
> What possibly could go wrong (except that 'unless' may
> be used as a variable name somewhere and that editors
> with syntax highlighting won't recognize it)? Or would
> it be to "alien" to most C programmers?
> 

A lot of people dislike the idea of "making your own language" in C, so
you can expect a fair resistance when other people are looking at your
code.  It will be hard to maintain, and hard for anyone other than you
to understand.

But some people like to use such macros in their programming.  I think
it is not worth the effort for a single case like this, but if you find
you have a range of such macros to give your programming a significantly
different flavour, then I don't think it is unreasonable - you end up
with your own language that conveniently uses a C compiler to do the
work.  Just don't expect other C programmers to like it!

But technically, I don't see any problems other than the ones you note.

[toc] | [prev] | [next] | [standalone]

#91641

In article <e0gh38F2552U1@mid.uni-berlin.de>,
 jt@toerring.de (Jens Thoms Toerring) wrote:

> Hi,
> 
>   everyone uses 'if' probably hundreds of times a day.
> But in some situations I'd feel that being able to use
> 'unless' instead, as in the trivial example
> 
>   unless (argc > 1) {
>       fprintf(stderr, "Missing argument(s)\n");
>       return EXIT_FAILURE;
>   }
> 
> might contribute to the readability of the code. Now,
> 'unless' isn't a C keyword (as it is in some other
> languages, e.g. Perl) but it seems easy to use a
> define like this
> 
> #define unless(expr) if (!(expr))
> 
> What possibly could go wrong (except that 'unless' may
> be used as a variable name somewhere and that editors
> with syntax highlighting won't recognize it)? Or would
> it be to "alien" to most C programmers?
> 
>                    Best regards, Jens

'unless' goes back at least as far as BCPL, and I've used it like you 
have a few times when it seemed appropriate. I don't understand why it 
wasn't put into C, except that it isn't truly necessary (but then by 
that argument, neither is the 'for' loop)

[toc] | [prev] | [next] | [standalone]

#91643

On Thursday, 4 August 2016 13:01:56 UTC+1, Mark Storkamp  wrote:
>  jt...@toerring.de (Jens Thoms Toerring) wrote:
> >   everyone uses 'if' probably hundreds of times a day.
> > But in some situations I'd feel that being able to use
> > 'unless' instead, as in the trivial example . . .
> 'unless' goes back at least as far as BCPL, and I've used it like you 
> have a few times when it seemed appropriate. I don't understand why it 
> wasn't put into C . . .
Agreed.  At least one other language offers both 
'do . . . while(cond)' and 'do . . . until(cond)',
only one of which is strictly necessary.
-- 

[toc] | [prev] | [next] | [standalone]

#91652

Mark Storkamp <mstorkamp@yahoo.com> writes:
[...]
> 'unless' goes back at least as far as BCPL, and I've used it like you 
> have a few times when it seemed appropriate. I don't understand why it 
> wasn't put into C, except that it isn't truly necessary (but then by 
> that argument, neither is the 'for' loop)

The difference, I think, is that `unless` is *trivially* unnecessary.
You can write the equivalent of a `for` loop using `while`, but it's
verbose and easy to get wrong.  `unless` just adds an implicit `!`.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#91700

Keith Thompson wrote:
> Mark Storkamp writes:
> > 'unless' goes back at least as far as BCPL, and I've used it like you 
> > have a few times when it seemed appropriate. I don't understand why it 
> > wasn't put into C, except that it isn't truly necessary (but then by 
> > that argument, neither is the 'for' loop)
> 
> The difference, I think, is that `unless` is *trivially* unnecessary.
> You can write the equivalent of a `for` loop using `while`, but it's
> verbose and easy to get wrong.  `unless` just adds an implicit `!`.

Some here would say that a for loop is verbose and easy to get wrong...

[toc] | [prev] | [next] | [standalone]

#91713

On 04/08/2016 16:45, Keith Thompson wrote:
> Mark Storkamp <mstorkamp@yahoo.com> writes:
> [...]
>> 'unless' goes back at least as far as BCPL, and I've used it like you
>> have a few times when it seemed appropriate. I don't understand why it
>> wasn't put into C, except that it isn't truly necessary (but then by
>> that argument, neither is the 'for' loop)
>
> The difference, I think, is that `unless` is *trivially* unnecessary.
> You can write the equivalent of a `for` loop using `while`, but it's
> verbose and easy to get wrong.  `unless` just adds an implicit `!`.

A for-loop isn't verbose enough?!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#91706

On Thursday, August 4, 2016 at 1:01:56 PM UTC+1, Mark Storkamp wrote:
> 
> 'unless' goes back at least as far as BCPL, and I've used it like you 
> have a few times when it seemed appropriate. I don't understand why it 
> wasn't put into C, except that it isn't truly necessary (but then by 
> that argument, neither is the 'for' loop)
>
C's for loop is unnecessarily general and can be abused.

But iterating over an array isn't the same operation as doing something
until a condition goes false. One's a deterministic mathematical process,
the other isn't. (Mathematicians don't like if statements).

However unless doesn't really add anything, except to allow
conditions to be written backwards

if(age < 18)
   childticket();

unless(age >= 18)
   childticket();
 
if(age >= 18)
  adultticket();

unless(age < 18)
   adultticket();

[toc] | [prev] | [next] | [standalone]

#91711

On 05/08/2016 09:17, Malcolm McLean wrote:
> On Thursday, August 4, 2016 at 1:01:56 PM UTC+1, Mark Storkamp wrote:
>>
>> 'unless' goes back at least as far as BCPL, and I've used it like you
>> have a few times when it seemed appropriate. I don't understand why it
>> wasn't put into C, except that it isn't truly necessary (but then by
>> that argument, neither is the 'for' loop)
>>
> C's for loop is unnecessarily general and can be abused.
>
> But iterating over an array isn't the same operation as doing something
> until a condition goes false. One's a deterministic mathematical process,
> the other isn't. (Mathematicians don't like if statements).
>
> However unless doesn't really add anything, except to allow
> conditions to be written backwards
>
> if(age < 18)
>    childticket();
>
> unless(age >= 18)
>    childticket();
>
> if(age >= 18)
>   adultticket();
>
> unless(age < 18)
>    adultticket();
>


Neither do you need >= and > since you can just use <= and <, and write 
the operands in reverse!

It just allows a more direct expression of what you're trying to do.

'unless' could be used for a condition which is expected to be generally 
true, as it is used in English. 'if' doesn't suggest the same degree of 
confidence.

Or for a condition where a false value implies an error condition.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#91719

On Friday, August 5, 2016 at 10:01:19 AM UTC+1, Bart wrote:
> On 05/08/2016 09:17, Malcolm McLean wrote:

> Neither do you need >= and > since you can just use <= and <, and write 
> the operands in reverse!
> 
That's what C++ does.

When writing generic functions that have a concept of "order", for example
a sort routine, the convention is to use templates to bind to the < operator.

So == is implemented as if( !(a < b) && !(b<a)) 

and so on. Caller then needs to provide only '<'  for his user-defined sortable 
class.  

[toc] | [prev] | [next] | [standalone]

#91726

In article <7421d23d-58d1-4b04-ab32-0bb5fde243af@googlegroups.com>,
 Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Thursday, August 4, 2016 at 1:01:56 PM UTC+1, Mark Storkamp wrote:
> > 
> > 'unless' goes back at least as far as BCPL, and I've used it like you 
> > have a few times when it seemed appropriate. I don't understand why it 
> > wasn't put into C, except that it isn't truly necessary (but then by 
> > that argument, neither is the 'for' loop)
> >
> C's for loop is unnecessarily general and can be abused.
> 
> But iterating over an array isn't the same operation as doing something
> until a condition goes false. One's a deterministic mathematical process,
> the other isn't. (Mathematicians don't like if statements).
> 

Conveniently then, since this is c.l.c, it was C's 'for' statement I was 
referring to.

When iterating over an array I personally would prefer 'foreach'. Or 
perhaps what we now know as 'for' could have been 'loop', and what I 
think of as 'foreach' could have been 'for'.

That's the fundamental problem with all languages. Someone made a 
decision, and not everybody will agree it was the correct one. We see 
that continually here with threads on how the language should be 
enhanced. Some people will always think it is good to continue to expand 
the language. Others will always think it is best to keep the core as 
unchanged as possible. Having tried python and seeing the mess of having 
two incompatible versions simultaneously supported puts me in the second 
camp.

[toc] | [prev] | [next] | [standalone]

#91796

On Friday, August 5, 2016 at 3:37:52 PM UTC+1, Mark Storkamp wrote:
> In article <7421d23d-58d1-4b04-ab32-0bb5fde243af@googlegroups.com>,
>  Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> 
> > On Thursday, August 4, 2016 at 1:01:56 PM UTC+1, Mark Storkamp wrote:
> > > 
> > > 'unless' goes back at least as far as BCPL, and I've used it like you 
> > > have a few times when it seemed appropriate. I don't understand why it 
> > > wasn't put into C, except that it isn't truly necessary (but then by 
> > > that argument, neither is the 'for' loop)
> > >
> > C's for loop is unnecessarily general and can be abused.
> > 
> > But iterating over an array isn't the same operation as doing something
> > until a condition goes false. One's a deterministic mathematical process,
> > the other isn't. (Mathematicians don't like if statements).
> > 
> 
> Conveniently then, since this is c.l.c, it was C's 'for' statement I was 
> referring to.
> 
> When iterating over an array I personally would prefer 'foreach'. Or 
> perhaps what we now know as 'for' could have been 'loop', and what I 
> think of as 'foreach' could have been 'for'.
> 
You often need the index number in the loop. foreach tends to 
accommodate ordered collections which are not held as arrays in
memory, but not operations which are a bit more complicated than
going through a list of employees and calling "payroll_pay()" on
each one. 

[toc] | [prev] | [next] | [standalone]

#91647

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
> >unless (argc > 1) {
> >    fprintf(stderr, "Missing argument(s)\n");
> >    return EXIT_FAILURE;
> >}

>   if( argc < 2 )
>   { fprintf( stderr, "Missing argument(s)\n" );
>     return EXIT_FAILURE; }

That's clear and that's why I wrote "trivial example". The
point is that many (most?) of my functions check their
arguments at the start. And usually this can be expressed
best with "unless the argument is in this or that range
get me out of here". A slightly less trivial example would
be

ssize_t read_into_buffer(unsigned char *buf, size_t len) {
    unless (buf && len)
        return INVALID_ARGS;
    ...
}

Of course, you can do that easily with

   if (!buf || !len)

or
   if (! (buf && len))

but with 'unless' the meaning would be somewhat clearer,
i.e. "unless these pre-requisites are satisfied we can't
go on" instead of "if these pre-requisistes are not satis-
fied we can't go on". With 'unless' you could express what
you need instead of explaining what you don't accept. One
less mental negation to do, which might help to avoid bugs
since you (or at least I) normally think in terms of what
is required instead of what's unacceptable;-)

                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#91648

On 04/08/2016 10:44, Jens Thoms Toerring wrote:
> Hi,
>
>   everyone uses 'if' probably hundreds of times a day.
> But in some situations I'd feel that being able to use
> 'unless' instead, as in the trivial example
>
>   unless (argc > 1) {
>       fprintf(stderr, "Missing argument(s)\n");
>       return EXIT_FAILURE;
>   }
>
> might contribute to the readability of the code. Now,
> 'unless' isn't a C keyword (as it is in some other
> languages, e.g. Perl) but it seems easy to use a
> define like this
>
> #define unless(expr) if (!(expr))
>
> What possibly could go wrong (except that 'unless' may
> be used as a variable name somewhere

I can't see a problem (except that people like to have macro names in 
capitals).

I use 'unless' in another language which can be translated to C. And 
there the translation uses exactly the same construct as yours, with a 
few extra parentheses:

Original source:

     unless a=0 then
         b:=c/a
     end

C output:

     if ((!(a==0)))
     {
         b=(c/a);
     }

(I can also write the above as:

     b:=c/a unless a=0

but this goes beyond the capabilities of the macro system.)

One thing about 'unless' is that it can get confusing in a chain:

  unless (a) {x;}
  else unless (b) {y;}
  else if (c) {z;}

So I keep uses of it simple.

  and that editors
> with syntax highlighting won't recognize it)? Or would
> it be to "alien" to most C programmers?

As someone has suggested, if you want to enhance the language with such 
macros, then you should be able to do so.

I would also add ones such as LEN() which replaces 
sizeof(a)/sizeof(a[0]), which saves writing the latter hundreds of 
times. Such things are not popular in this newsgroup, but ignore that...

Not having syntax highlighting support can be a problem. Although 
individual apps might have a way of extending the set of keywords that 
are recognised.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#91649

On Thursday, 4 August 2016 10:44:20 UTC+1, Jens Thoms Toerring  wrote:

> #define unless(expr) if (!(expr))
> 
> What possibly could go wrong ...? Or would
> it be to "alien" to most C programmers?

https://utcc.utoronto.ca/~cks/space/blog/programming/BourneGol is just
waiting to be reimplemented, obviously.

[toc] | [prev] | [next] | [standalone]

#91653

jt@toerring.de (Jens Thoms Toerring) writes:
>   everyone uses 'if' probably hundreds of times a day.
> But in some situations I'd feel that being able to use
> 'unless' instead, as in the trivial example
>
>   unless (argc > 1) {
>       fprintf(stderr, "Missing argument(s)\n");
>       return EXIT_FAILURE;
>   }
>
> might contribute to the readability of the code. Now,
> 'unless' isn't a C keyword (as it is in some other
> languages, e.g. Perl) but it seems easy to use a
> define like this
>
> #define unless(expr) if (!(expr))
>
> What possibly could go wrong (except that 'unless' may
> be used as a variable name somewhere and that editors
> with syntax highlighting won't recognize it)? Or would
> it be to "alien" to most C programmers?

In my opinion, adding an `unless` keyword to C wouldn't be harmful, but
it wouldn't be useful enough to justify the change.  It would also add
new opportunities for the IOCCC:

    unless (! (x != y)) ...

Perl has `unless`, and I write a lot of Perl code.  I hardly ever use
`unless` -- and when I do always in the postfix form:

    do_this() unless <some_condition>;

One drawback of the `if (!expr)` form is that `!` is a single
character that can sometimes be easy to miss.  Adding a space:
`if (! expr)` helps a bit.  One nice thing about Perl is that you can
write `not` rather than `!`. You can do the same in C with `#include
<iso646.h>`, but that's unfamiliar enough that I don't use it myself.

(I make no claim that I'm entirely consistent.0

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#91657

On Thursday, August 4, 2016 at 10:52:33 AM UTC-5, Keith Thompson wrote:
> One drawback of the `if (!expr)` form is that `!` is a single
> character that can sometimes be easy to miss.  Adding a space:
> `if (! expr)` helps a bit.  One nice thing about Perl is that you can
> write `not` rather than `!`. You can do the same in C with `#include
> <iso646.h>`, but that's unfamiliar enough that I don't use it myself.

IMHO, that's less of an issue than the fact that ! only binds to the first
term, rather than inverting the entire expression.  Given a collection
of "if" statements some of which test affirmative conditions and some of
which test negative conditions, it becomes necessary to either use different
levels of nesting on positive and negative expressions, use doubled-up
parentheses on the positive expressions, or else add a redundant double-
invert on the positive ones.

Extending the grammar by having "if" and "while" accept a
"conditional-expression" which is satisfied by either "(expression)"
or "!conditional-expression" would quite easily resolve that issue,
though I doubt the issue is a big enough problem to justify the change.

[toc] | [prev] | [next] | [standalone]

#91659

supercat@casperkitty.com writes:
> On Thursday, August 4, 2016 at 10:52:33 AM UTC-5, Keith Thompson wrote:
>> One drawback of the `if (!expr)` form is that `!` is a single
>> character that can sometimes be easy to miss.  Adding a space:
>> `if (! expr)` helps a bit.  One nice thing about Perl is that you can
>> write `not` rather than `!`. You can do the same in C with `#include
>> <iso646.h>`, but that's unfamiliar enough that I don't use it myself.
>
> IMHO, that's less of an issue than the fact that ! only binds to the first
> term, rather than inverting the entire expression.  Given a collection
> of "if" statements some of which test affirmative conditions and some of
> which test negative conditions, it becomes necessary to either use different
> levels of nesting on positive and negative expressions, use doubled-up
> parentheses on the positive expressions, or else add a redundant double-
> invert on the positive ones.
>
> Extending the grammar by having "if" and "while" accept a
> "conditional-expression" which is satisfied by either "(expression)"
> or "!conditional-expression" would quite easily resolve that issue,
> though I doubt the issue is a big enough problem to justify the change.

So the meaning of

    ! x == y

would differ depending on whether it appears as the condition for an
"if" or "while" (or, presumably "for", or "do-while", or "?:") or in
some other context.

No thanks!

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#91662

Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>> On Thursday, August 4, 2016 at 10:52:33 AM UTC-5, Keith Thompson wrote:
>>> One drawback of the `if (!expr)` form is that `!` is a single
>>> character that can sometimes be easy to miss.  Adding a space:
>>> `if (! expr)` helps a bit.  One nice thing about Perl is that you can
>>> write `not` rather than `!`. You can do the same in C with `#include
>>> <iso646.h>`, but that's unfamiliar enough that I don't use it myself.
>>
>> IMHO, that's less of an issue than the fact that ! only binds to the first
>> term, rather than inverting the entire expression.  Given a collection
>> of "if" statements some of which test affirmative conditions and some of
>> which test negative conditions, it becomes necessary to either use different
>> levels of nesting on positive and negative expressions, use doubled-up
>> parentheses on the positive expressions, or else add a redundant double-
>> invert on the positive ones.
>>
>> Extending the grammar by having "if" and "while" accept a
>> "conditional-expression" which is satisfied by either "(expression)"
>> or "!conditional-expression" would quite easily resolve that issue,
>> though I doubt the issue is a big enough problem to justify the change.
>
> So the meaning of
>
>     ! x == y
>
> would differ depending on whether it appears as the condition for an
> "if" or "while" (or, presumably "for", or "do-while", or "?:") or in
> some other context.
>
> No thanks!

I think the suggestion is that you could write if !(exp) and/or
while !(exp) thus avoiding the extra parentheses.  (The required grammar
is sketched in supercats's text, but I think it's been brought up
before.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#91664

On Thursday, August 4, 2016 at 1:39:30 PM UTC-5, Ben Bacarisse wrote:
> I think the suggestion is that you could write if !(exp) and/or
> while !(exp) thus avoiding the extra parentheses.  (The required grammar
> is sketched in supercats's text, but I think it's been brought up
> before.)

Precisely.  From a parsing standpoint, it's not really necessary to have a
parenthesis before the conditional expression, but it is necessary to have
something that marks the end of the conditional expression; C uses a the
first closing parenthesis that does not balance an inner parenthesis for
that purpose.  As such, allowing anything related to the conditional
expression to appear after the closing parenthesis would cause parsing
difficulties, but allowing certain things before the opening parentheses
would not.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web