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 2 of 2 — ← Prev page 1 [2]

#91670

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> supercat@casperkitty.com writes:
>>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;
>
>   Why?
>
>   For example, in,
>
> if x > 0 && y < 11 printf( "ok." );
>
>   , or,
>
> if x > 0 && y < 11 { puts( "ok." ); puts( "fine" ); }
>
>   the expression that begins with »x« cannot be continued
>   with »printf« or »{«, so it must end with »11«.

Consider

  if x > 0 && y < 11 + printf( "ok." );

(Unlikely code, but it seems best to stick as closely as possible to
your example.)

-- 
Ben.

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

#91671

On 04/08/2016 20:20, Stefan Ram wrote:
> supercat@casperkitty.com writes:
>> 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;
>
>   Why?
>
>   For example, in,
>
> if x > 0 && y < 11 printf( "ok." );
>
>   , or,
>
> if x > 0 && y < 11 { puts( "ok." ); puts( "fine" ); }
>
>   the expression that begins with »x« cannot be continued
>   with »printf« or »{«, so it must end with »11«.


What about:          Without () is parsed as:

  if (a) -b;          if a-b;
  if (a) *b;          if a*b;
  if (a) &b;          if a&b;
  if ("a") "b";       if "ab";
  if (a) (int)b;      if a(int)... // looks like a function call

etc.

There needs to be a tidy way of denoting the boundary between condition 
and statement. Such as ")", "then" or ":". It helps the reader as well 
as the compiler.

-- 
Bartc

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

#91717

On 04/08/16 21:42, BartC wrote:
> On 04/08/2016 20:20, Stefan Ram wrote:
>> supercat@casperkitty.com writes:
>>> 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;
>>
>>   Why?
>>
>>   For example, in,
>>
>> if x > 0 && y < 11 printf( "ok." );
>>
>>   , or,
>>
>> if x > 0 && y < 11 { puts( "ok." ); puts( "fine" ); }
>>
>>   the expression that begins with »x« cannot be continued
>>   with »printf« or »{«, so it must end with »11«.
> 
> 
> What about:          Without () is parsed as:
> 
>  if (a) -b;          if a-b;
>  if (a) *b;          if a*b;
>  if (a) &b;          if a&b;
>  if ("a") "b";       if "ab";
>  if (a) (int)b;      if a(int)... // looks like a function call
> 
> etc.
> 
> There needs to be a tidy way of denoting the boundary between condition
> and statement. Such as ")", "then" or ":". It helps the reader as well
> as the compiler.
> 

If you want to change the grammar of "if" in C in a way that could be
consistent and safe, just make the brackets compulsory:

	if /cond/ { statements };

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

#91720

David Brown <david.brown@hesbynett.no> writes:

> On 04/08/16 21:42, BartC wrote:
<snip>
>> There needs to be a tidy way of denoting the boundary between condition
>> and statement. Such as ")", "then" or ":". It helps the reader as well
>> as the compiler.
>
> If you want to change the grammar of "if" in C in a way that could be
> consistent and safe, just make the brackets compulsory:
>
> 	if /cond/ { statements };

As Go did.  Alternatively you could permit only a subset of statements
after a bracketless if (or while).  Exactly which ones would be
debatable, but I'd go for those that start with a "statement" keyword
(if, while, return and so on), compound statements (as above) and ;.
Probably not worth it since the most common case (an expression
statement with a function call) would still need {}s.

-- 
Ben.

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

#91705

On Thursday, 4 August 2016 16:52:33 UTC+1, Keith Thompson  wrote:

> One drawback of the `if (!expr)` form is that `!` is a single
> character that can sometimes be easy to miss.

A software engineer I know of uses the not-not-not form for that
reason :-
      if (!!!expr) { ... }

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

#91676

On 8/4/2016 5:44 AM, 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
> 

I'm going to differ with most of the others here.  I think the could be
a useful addition.  It could simplify a complex if condition.

Many times I've duplicated something like this with;

if (complex_condition) {
  ;
}
else {
   do something here;
}

Which has the same results, but I don't think it quite as clear.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#91718

On 04/08/16 22:43, Jerry Stuckle wrote:
> On 8/4/2016 5:44 AM, 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
>>
> 
> I'm going to differ with most of the others here.  I think the could be
> a useful addition.  It could simplify a complex if condition.
> 
> Many times I've duplicated something like this with;
> 
> if (complex_condition) {
>   ;
> }
> else {
>    do something here;
> }
> 
> Which has the same results, but I don't think it quite as clear.
> 

I've done that occasionally, if it fitted a pattern with existing code.
 I put a comment on the "blank" line to make it clear that it is
intentional.

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

#91692

Hi,

   to summarize: there don't seem to be anything
"technically broken" with a macro like

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

or also

#define until(expr) while (! (expr))

in the sense that there would be cornercases where
it would do something quite different from what it
obviously was intended to do. That's the good side.

Note: I hadn't considered an 'unless' keyword as some-
thing the C language would need urgently, it has done
quite well for a very long time without;-) A macro
like that (maybe just for use in some not too public
projects) would do, as far as I can see.

The other issue is how "disgusting" it is to other
people looking at the code. Of course, there's some
startling factor - there's something that looks like
a keyword, but one you haven't seen before and, while
its meaning looks rather obvious, you can't say for sure
if it really does what you expect until you have hunted
down its definition in sone header file and made sure
that it actually does what you expected. That's a good
argument against using it, at least in code other people
have to work with. And another issue would be constructs
like

  unless (something) {
      ...
  } else unless (something_else) {
      ...
  } else {
      ...
  }

or, perhaps worse, mixing 'unless' and 'if',

  unless (something) {
      ....
  } else if (something_else) {
      ...
  } else {
      ...
  }

which might be confusing, perhaps mostly due to un-
familiarity.

Do you disagree with these conclusions?

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

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

#91693

jt@toerring.de (Jens Thoms Toerring) writes:

> Hi,
>
>    to summarize: there don't seem to be anything
> "technically broken" with a macro like
>
> #define unless(expr) if (! (expr))
>
> or also
>
> #define until(expr) while (! (expr))
>
> in the sense that there would be cornercases where
> it would do something quite different from what it
> obviously was intended to do. That's the good side.
>
> Note: I hadn't considered an 'unless' keyword as some-
> thing the C language would need urgently, it has done
> quite well for a very long time without;-) A macro
> like that (maybe just for use in some not too public
> projects) would do, as far as I can see.
>
> The other issue is how "disgusting" it is to other
> people looking at the code. Of course, there's some
> startling factor - there's something that looks like
> a keyword, but one you haven't seen before and, while
> its meaning looks rather obvious, you can't say for sure
> if it really does what you expect until you have hunted
> down its definition in sone header file and made sure
> that it actually does what you expected. That's a good
> argument against using it, at least in code other people
> have to work with. And another issue would be constructs
> like
>
>   unless (something) {
>       ...
>   } else unless (something_else) {
>       ...
>   } else {
>       ...
>   }

Some languages distinguish between conditionals that can have an 'else'
and those that can't.  For example, Lisp has (when ...) and (unless ...)
which don't have an else branch and BCPL has 'if E do C' and 'unless E
do C' with 'test E then C1 or C2' for the double armed condition.

You could do that here with something like

  #define unless(test) if (test); else

which would make the above be a syntax error.

<snip>
-- 
Ben.

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

#91698

jt@toerring.de (Jens Thoms Toerring) writes:

> Hi,
>
>    to summarize:  there don't seem to be anything
> "technically broken" with a macro like
>
> #define unless(expr) if (!  (expr))
>
> or also
>
> #define until(expr) while (!  (expr))
>
> in the sense that there would be cornercases where
> it would do something quite different from what it
> obviously was intended to do.  That's the good side.
>
> Note:  I hadn't considered an 'unless' keyword as some-
> thing the C language would need urgently, it has done
> quite well for a very long time without;-) A macro
> like that (maybe just for use in some not too public
> projects) would do, as far as I can see.
>
> The other issue is how "disgusting" it is to other
> people looking at the code.  Of course, there's some
> startling factor - there's something that looks like
> a keyword, but one you haven't seen before and, while
> its meaning looks rather obvious, you can't say for sure
> if it really does what you expect until you have hunted
> down its definition in sone header file and made sure
> that it actually does what you expected.  That's a good
> argument against using it, at least in code other people
> have to work with.  And another issue would be constructs
> like
>
>   unless (something) {
>       ...
>   } else unless (something_else) {
>       ...
>   } else {
>       ...
>   }
>
> or, perhaps worse, mixing 'unless' and 'if',
>
>   unless (something) {
>       ....
>   } else if (something_else) {
>       ...
>   } else {
>       ...
>   }
>
> which might be confusing, perhaps mostly due to un-
> familiarity.
>
> Do you disagree with these conclusions?

Sorry to be a bit late to the party.  A few comments.

One:  I'm not enthusiastic in general about using the
preprocessor to provide syntactic extensions.  However this
situation may be common enough to get it above threshold.  A
lot of times it helps to be able to express a condition in
negative logic rather than positive logic, and having a
standard idiom to do that would be helpful.

Two:  I'm not wild about 'unless' as the keyword.  The
mixing example above shows one reason why.  Another reason
is that 'unless' suggests (at least to me it does) that the
body of the 'unless' is typically expected to execute (ie,
that the condition will usually be false).  Even though the
suggestion may be mild, it seems a bad idea to give that
impression by using 'unless'.  IMO 'ifnot' is better, the
choices made in other languages notwithstanding.  Here
are the above exampless, re-written to use ifnot():

    ifnot (something) {
        ...
    } else ifnot (something_else) {
        ...
    } else {
        ...
    }
    
    ifnot (something) {
        ....
    } else if (something_else) {
        ...
    } else {
        ...
    }

To me these look okay now.  What do y'all think?


Three:  If we want the new keyword to parallel 'if()'
exactly, which I think we should, the proposed macro
definition is incomplete.  In C99 we could write a
macro definition this way:

    #define ifnot(...)  if( ! (__VA_ARGS__) )

I know, some people despise the comma operator, and would
just as soon pretend it doesn't exist.  But I think
violating the Law of Least Astonishment is worse.

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

#91721

jt@toerring.de (Jens Thoms Toerring) writes:

One additional thought.

It occurs to me we can leave 'if' alone and approach
the problem somewhat differently:

    #define NOT(...)  ( ! (__VA_ARGS__) )

This macro can be used in conjunction with regular if()
constructs:

    if NOT(something) {
        ...
    } else if NOT(something_else) {
        ...
    } else {
        ...
    }

    if NOT(something) {
        ....
    } else if (something_else) {
        ...
    } else {
        ...
    }

and also could be used in conjunction with while()
statements or do ... while() statements:

    while NOT( i-- == 0 )  ...

    do {
        ...
    } while NOT( finished );

This approach makes the associated syntactic skulduggery more
obvious.  Personally I think the "new keyword" approach is a
better choice, but other folks may have a different reaction.

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

#91722

On 05/08/2016 12:57, Tim Rentsch wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
>
> One additional thought.
>
> It occurs to me we can leave 'if' alone and approach
> the problem somewhat differently:
>
>     #define NOT(...)  ( ! (__VA_ARGS__) )
>
> This macro can be used in conjunction with regular if()
> constructs:
>
>     if NOT(something) {

>
>     while NOT( i-- == 0 )  ...
>
>     do {
>         ...
>     } while NOT( finished );

Nice, but partly defeats the purpose of using 'unless', or 'until' for 
the loop example.

Which is to make the condition more obvious, not to add yet another 
level of logic!

And where the condition starts with ! anyway, the NOT(!...) is even more 
confusing (then you have to start weeding these out, but before you know 
it, you're reversing entire boolean expressions).

It's also perverse to define NOT, when the language also apparently uses 
"!" and "not" (in iso646.h) with similar meanings.

-- 
Bartc

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

#92459

BartC <bc@freeuk.com> writes:

> On 05/08/2016 12:57, Tim Rentsch wrote:
>> jt@toerring.de (Jens Thoms Toerring) writes:
>>
>> One additional thought.
>>
>> It occurs to me we can leave 'if' alone and approach
>> the problem somewhat differently:
>>
>>     #define NOT(...)  ( ! (__VA_ARGS__) )
>>
>> This macro can be used in conjunction with regular if()
>> constructs:
>>
>>     if NOT(something) {
>> [...]
>>     while NOT( i-- == 0 )  ...
>>
>>     do {
>>         ...
>>     } while NOT( finished );
>
> Nice, but partly defeats the purpose of using 'unless', or 'until' for
> the loop example.  [snip elaboration]

Like any other not-completely-trivial technical problem, every
approach to solving such a problem is going to have minuses as
well as pluses.

This observation should make you happy - since your goal in life
is to be a complaining asshole, there will always be something
for you to complain about.

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

#92462

On 18/08/2016 16:11, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 05/08/2016 12:57, Tim Rentsch wrote:

>>>     if NOT(something) {
>>> [...]
>>>     while NOT( i-- == 0 )  ...
>>>
>>>     do {
>>>         ...
>>>     } while NOT( finished );
>>
>> Nice, but partly defeats the purpose of using 'unless', or 'until' for
>> the loop example.  [snip elaboration]
>
> Like any other not-completely-trivial technical problem, every
> approach to solving such a problem is going to have minuses as
> well as pluses.
>
> This observation should make you happy - since your goal in life
> is to be a complaining *******

With plenty of justification when it comes to C.

I was only an amateur language designer in the 80s, yet my languages had 
hardly any of the issues that seem to plague C (but which everyone still 
defends).

If I can do it, then so could anyone, you would think.

At the minute C is just about a half-reasonable intermediate language 
for a translator back-end (once you've done battle with the type syntax 
and type system, and dropped half-a-dozen features that can't be 
expressed). But I genuinely feel sorry for those who have to use it 
hands-on, especially beginners.


(BTW you've done your own share of being a complaining ******** when it 
comes to stuff such as binary literals and numeric separators...)

-- 
Bartc

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

#92474

On Thursday, August 18, 2016 at 10:36:52 AM UTC-5, Bart wrote:
> I was only an amateur language designer in the 80s, yet my languages had 
> hardly any of the issues that seem to plague C (but which everyone still 
> defends).

The problem with C is that the C89 Committee took the view that:

  (1) It should avoid imposing any behavioral mandates that would prevent
      a conforming implementation from processing any existing code as
      efficiently as an existing implementation for the same platform.

  (2) In cases where a construct is so obviously useful and practical on
      certain kinds of platforms that implementations targeting such
      platforms unanimously support it, there is no need to mandate such
      behavior.

If an existing compiler had a very strict interpretation of type-based
aliasing which was working well for the programs people wanted to use
with it, the authors of the Standard didn't want to mandate that it
change in a way that would make it less efficient at processing the
programs targeting it.

Unfortunately, compiler writers seem to regard the fact that a construct
need not be supported to make a compiler comply with the Standard as
implying that the construct need not be supported to make the compiler
maximally useful.

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

#91870

On Thursday, August 4, 2016 at 10:44:20 AM UTC+1, 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

To be honest, I think the example you give would be better written with an "if". To my mind, this code:

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

suggests that you are planning on printing an error message, but you will forego this if the user supplies suitable arguments. Whereas this code:

[From Stefan Ram, I believe]

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

suggests that you intend to run the function, but will bail out early if the user has not provided suitable arguments. Which is presumably what the programmer intended.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web