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

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

New C operator -- would it be a good idea?

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

Contents

  New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-10 12:48 -0700
    Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 14:27 -0400
      Re: New C operator -- would it be a good idea? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-09-11 16:53 -0700
    Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-11 19:24 +0000
      Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 15:56 -0400
        Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-11 14:15 -0700
        Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:56 -0700
          Re: New C operator -- would it be a good idea? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 00:56 -0700
            Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:55 +0100
              Re: New C operator -- would it be a good idea? "io_x" <a@b.c.invalid> - 2012-09-13 07:47 +0200
                Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 10:47 +0100
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:25 -0700
        Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-12 09:39 +0200
          Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 08:33 -0700
            Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-13 09:53 +0200
      Re: New C operator -- would it be a good idea? falk@rahul.net (Edward A. Falk) - 2012-09-12 17:43 +0000
        Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 15:35 -0700
        Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-13 06:34 +0000
          Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 11:47 +0100
        Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-13 23:52 -0700
          Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-14 07:53 +0000
            Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 11:46 +0100
              Re: New C operator -- would it be a good idea? JohnF <john@please.see.sig.for.email.com> - 2012-09-14 13:17 +0000
            Re: New C operator -- would it be a good idea? John Bode <jfbode1029@gmail.com> - 2012-09-14 11:35 -0700
          Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-14 02:04 -0700
          Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-14 21:11 +0000
        Re: New C operator -- would it be a good idea? Ben Pfaff <blp@cs.stanford.edu> - 2012-09-14 11:39 -0700
    Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-11 22:32 +0100
      Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-11 15:19 -0700
    Re: New C operator -- would it be a good idea? gordonb.22y0w@burditt.org (Gordon Burditt) - 2012-09-11 17:27 -0500
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 18:51 -0700
        Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:49 +0100
        Re: New C operator -- would it be a good idea? Greg Martin <greg@softsprocket.com> - 2012-09-12 23:23 -0700
          Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 12:08 +0100
            Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-13 15:20 -0700
        Re: New C operator -- would it be a good idea? gordonb.h093l@burditt.org (Gordon Burditt) - 2012-09-14 15:13 -0500
    Re: New C operator -- would it be a good idea? Rui Maciel <rui.maciel@gmail.com> - 2012-09-14 20:38 +0100

Page 1 of 2  [1] 2  Next page →

#26204 — New C operator -- would it be a good idea?

Hi.

I was wondering about this. I saw this posting on this site:

http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator

where they were mentioning a fake "operator", an artifact of how the C
language is interpreted, that looked like it caused the value of a
variable to "go to" another. Namely, "x --> 0" in the code was just
"x-- > 0", giving it the appearance of having the effect of
"incrementing x toward 0". Now, I was wondering: would this be a good
idea for a new real operator for the C language? Namely, "a -->
b" (and "b <-- a") as real operators that could increment a toward b.
Or would it be pretty worthless?

[toc] | [next] | [standalone]

#26219

"mike3" <mike4ty4@yahoo.com> wrote in message 
news:fe55af6c-8fd3-4130-9a6e-6838ff600111@q7g2000pbj.googlegroups.com...
> Hi.
>
> I was wondering about this. I saw this posting on this site:
>
> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator
>
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?

Whenever you're talking about a language extension, you need to consider 
some things:

- How much would this extension improve the language?  Would it make it 
easier to make maintainable, reliable programs?  Would it allow the compiler 
to improve the code generation for a significant number of programs?

- How much would this extension cost?  After all, extending the language 
implies that every programmer needs to remember this additional operator 
(even if they don't use it themselves, they may run into it while reading 
other people's programs).  In addition, adding this would require that every 
compiler also implement it.

So, what's the result of this cost/benefit analysis?  Well, I don't see much 
benefit at all; I can't think of that many places where this would be 
heavily used, and where it is, this long-hand form would look quite 
appropriate, both for the humans reading/maintaining the code, and the 
compiler processing the code:

   if (b < a) {
       a -= 1;   /* b is below; move a somewhat closer to b */
   } else if (b > a) {
       a += 1;   /* b is above, move a somewhat closer to b */
   } else {
       /* a == b; keep a where it is */
   }

So, virtually no benefit at some nonzero cost; it doesn't look worth it to 
me.

-- 
poncho

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

#26229

On Sep 11, 7:28 pm, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:

>    if (b < a) {
>        a -= 1;   /* b is below; move a somewhat closer to b */
>    } else if (b > a) {
>        a += 1;   /* b is above, move a somewhat closer to b */
>    } else {
>        /* a == b; keep a where it is */
>    }

And in many, many years of programming in C and similar languages, I
am quite sure that I haven't used this particular construct one single
time. Therefore, I wouldn't have used this bizarre operator one single
time.

What about something useful instead: Like a built-in min () and max ()
function:

min (a, b) is the same as (a < b ? a : b) except that a and b are
evaluated only once and there is no sequence point introduced; the
expressions a and b must be such that the expression on the right side
is valid. Similar for max (a, b). And both functions can have three or
more arguments as well: max (a, b, c) = max (max (a, b), c). (min (a)
and max (a) might be allowed as extreme cases).

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

#26220

On 2012-09-10, mike3 <mike4ty4@yahoo.com> wrote:
> Hi.
>
> I was wondering about this. I saw this posting on this site:
>
> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator
>
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?

I can give you five reasons why not.

1. It would be worthless because using it would make your code nonportable to all
   the compilers which have decided to ignore implementing such a thing.
   The best feature of C is stability, and the best dialect for that is ISO C90,
   (with perhaps some very judicious use of new-fangled libraries from C99 and C11.)

2. The --> and <-- syntax has an existing meaning. It is tokenized as {--}{>}
   and {<}{--}.  The expression a-->b is already valid C. It means (a--) > (b).
   In other words, decrement a, and test whether the prior value is greater than b.
   So your proposal horribly breaks the current language, making it a complete
   nonstarter.

3. Not having b <-- a, you have to write something like a = (a < b) ? a + 1 : a - 1;
   This is not a big deal and you can hide it behind a macro, except that it evaluates
   a twice:

     #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)

   See? You can implement the operator in C already, just not with the syntax you want,
   and with a small semantic concession. But this means that the --> operator
   does not express anything which cannot be expressed already, it just makes a
   small, incremental semantic improvement over the macro. A small, incremental
   improvement is harder to justify. Moreover, the syntax that you want breaks
   the existing syntax (point 2 above), whereas the INCTOWARD macro doesn't.

4. There is no corresponding machine instruction in any popular machine
   instruction set, so you're not going to get better code by providing an inctoward
   operator in the language.  And even if there is a single machine instruction
   for doing (A < B ? A + 1 : A - 1), a compiler just has to recognize this
   syntax tree pattern, and check a few constraints and then use the
   instruction. It is not strictly necessary to have a dedicated operator. 
   For instance, some instruction sets have a division instruction which yields both
   the quotient and the modulus. Compilers recognize code like
   a = b / c; d = b % c and emit just one division instruction from which the
   quotient and modulus are obtained for a and d.

5. A trivial new arithmetic operator is not going to lend expressivity to the C language.
   And anyway, programmers don't need C to be expressive. By and large they
   need it to be a "portable assembler". If you want expressivity, you invent
   another programming language and then interpret it with C, or compile it to C.
   That language can easily have an A <-- B operator, which expands into
   the appropriate C (with clean evaluation semantics and everything).

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

#26221

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20120911115303.248@kylheku.com...
>
> 3. Not having b <-- a, you have to write something like a = (a < b) ? a + 
> 1 : a - 1;
>   This is not a big deal and you can hide it behind a macro, except that 
> it evaluates
>   a twice:
>
>     #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)

That gives us Yet Another reason (beyond what Kaz and I already listed): 
what exactly is the desired behavior?  Specifically, what should the 
operator do if a==b initially?

My longhand version assumed one behavior (a remains the same), while Kaz's 
version assumed another (a is decremented).  Which is correct?  Well, that 
depends entirely on what the original programmer meant; in longhand, he can 
easily select either behavior (or something else entirely if that's 
appropriate).

However, if we have a built-in 'b <-- a' operator, well, the language has to 
specify exactly what the behavior is (and if it makes it 
unspecified/implemented-defined or undefined, well, that means that the 
programmer generally can't depend on it).

So, to that extent, this proposed built-in would have less expressiveness 
than what's already in the language.

-- 
poncho

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

#26222

"Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:
[...]
> However, if we have a built-in 'b <-- a' operator, well, the language has to 
> specify exactly what the behavior is (and if it makes it 
> unspecified/implemented-defined or undefined, well, that means that the 
> programmer generally can't depend on it).
[...]

And of course we can't use that syntax for a new operator, since
    b <-- a
already has a well defined meaning.

(Conceivably you could define a new "<--" operator that's 100%
compatible with all possible occurrences of "< --", but I'm skeptical
that that would be both possible and useful.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#26228

On Sep 11, 1:57 pm, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:
> "Kaz Kylheku" <k...@kylheku.com> wrote in message
>
> news:20120911115303.248@kylheku.com...
>
>
>
> > 3. Not having b <-- a, you have to write something like a = (a < b) ? a +
> > 1 : a - 1;
> >   This is not a big deal and you can hide it behind a macro, except that
> > it evaluates
> >   a twice:
>
> >     #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)
>
> That gives us Yet Another reason (beyond what Kaz and I already listed):
> what exactly is the desired behavior?  Specifically, what should the
> operator do if a==b initially?
>
> My longhand version assumed one behavior (a remains the same), while Kaz's
> version assumed another (a is decremented).  Which is correct?  Well, that
> depends entirely on what the original programmer meant; in longhand, he can
> easily select either behavior (or something else entirely if that's
> appropriate).
>
> However, if we have a built-in 'b <-- a' operator, well, the language has to
> specify exactly what the behavior is (and if it makes it
> unspecified/implemented-defined or undefined, well, that means that the
> programmer generally can't depend on it).
>
> So, to that extent, this proposed built-in would have less expressiveness
> than what's already in the language.
>

What I was thinking of was that a --> b when a == b should leave a
unchanged.
Because the idea is that with repeated application, a converges to b,
or
a "goes to" b. So when a == b, a should remain unchanged, as it is
"already
there".

However, as for this "expressiveness" issue: the question comes down
to whether
or not it'd be a good idea to have certain things made into a short-
hand, easily-
available form or not. That is, is it more _convenient_ -- does it
make things
_easier_ if we had -->. Wouldn't it be nice to know it's there if you
need it,
so you don't have to code that extra macro or whatever?

I do however, wonder in light of this point, which kind of what-to-do-
when-the-
values-are-equal behavior is used most often in actual real uses of
this operation
(written without this operat_or_, of course).

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

#26232

On Sep 11, 11:56 pm, mike3 <mike4...@yahoo.com> wrote:
> On Sep 11, 1:57 pm, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:
> > "Kaz Kylheku" <k...@kylheku.com> wrote in message
> >news:20120911115303.248@kylheku.com...

[the inc-toward operator]

> > > 3. Not having b <-- a, you have to write something like a = (a < b) ? a +
> > > 1 : a - 1;

<snip>

> > [...]  Specifically, what should the operator do if a==b initially?

<snip>

> What I was thinking of was that a --> b when a == b should leave a
> unchanged.
> Because the idea is that with repeated application, a converges to b,
> or
> a "goes to" b. So when a == b, a should remain unchanged, as it is
> "already
> there".
>
> However, as for this "expressiveness" issue: the question comes down
> to whether
> or not it'd be a good idea to have certain things made into a short-
> hand, easily-
> available form or not. That is, is it more _convenient_ -- does it
> make things
> _easier_ if we had -->. Wouldn't it be nice to know it's there if you
> need it,
> so you don't have to code that extra macro or whatever?

but how would you use it? With an approriate return value
this:-

for (i = 0; i < 10; i++)
   do_something (i);

could be

i = 0;
while (i --> 10)
   do_something (i);

but I'm not sure this buys you much.

> I do however, wonder in light of this point, which kind of what-to-do-
> when-the-
> values-are-equal behavior is used most often in actual real uses of
> this operation
> (written without this operat_or_, of course.


I'm simply failign to see the point

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

#26235

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:3be17a87-2054-4b7a-86dc-bcbce835bca5@d7g2000vbv.googlegroups.com...
> On Sep 11, 11:56 pm, mike3 <mike4...@yahoo.com> wrote:

> but how would you use it? With an approriate return value
> this:-
>
> for (i = 0; i < 10; i++)
>   do_something (i);
>
> could be
>
> i = 0;
> while (i --> 10)
>   do_something (i);

This looks like it will loop forever (more than 10 times anyway), unless the 
'value' of i-->10 is neither i nor 10. It would have return 0 when it's 
reached the target, and 1 otherwise.

-- 
Bartc 

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

#26285

"BartC" <bc@freeuk.com> ha scritto nel messaggio
news:k2pmd0$vuq$1@dont-email.me...
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
> news:3be17a87-2054-4b7a-86dc-bcbce835bca5@d7g2000vbv.googlegroups.com...
>> On Sep 11, 11:56 pm, mike3 <mike4...@yahoo.com> wrote:
>
>> but how would you use it? With an approriate return value
>> this:-
>>
>> for (i = 0; i < 10; i++)
>>   do_something (i);
>>
>> could be
>>
>> i = 0;
>> while (i --> 10)
>>   do_something (i);

> This looks like it will loop forever (more than 10 times anyway), unless the

if "i" begin from 0 i-- would return 0 !> 10 so exit in the first iteration

> 'value' of i-->10 is neither i nor 10. It would have return 0 when it's
> reached the target, and 1 otherwise.

the loop eqivalent could be
i = 10;
while(i-- > 0)       //10,9,...1
   do_something(i);  // 9,8,...0

but i never use it...

> -- 
> Bartc

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

#26291

"io_x" <a@b.c.invalid> wrote in message 
news:505171e5$0$13284$4fafbaef@reader2.news.tin.it...
>
> "BartC" <bc@freeuk.com> ha scritto nel messaggio
> news:k2pmd0$vuq$1@dont-email.me...
>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
>> news:3be17a87-2054-4b7a-86dc-bcbce835bca5@d7g2000vbv.googlegroups.com...
>>> On Sep 11, 11:56 pm, mike3 <mike4...@yahoo.com> wrote:
>>
>>> but how would you use it? With an approriate return value
>>> this:-
>>>
>>> for (i = 0; i < 10; i++)
>>>   do_something (i);
>>>
>>> could be
>>>
>>> i = 0;
>>> while (i --> 10)
>>>   do_something (i);
>
>> This looks like it will loop forever (more than 10 times anyway), unless 
>> the
>
> if "i" begin from 0 i-- would return 0 !> 10 so exit in the first 
> iteration

But "-->" operates immediately, so the first value of (i-->10) would be 1.

(Don't forget we're discussing a new, proposed "-->" operator and not "--" 
followed by ">")

-- 
Bartc 

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

#26226

On Sep 11, 1:24 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2012-09-10, mike3 <mike4...@yahoo.com> wrote:
>
> > Hi.
>
> > I was wondering about this. I saw this posting on this site:
>
> >http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-o...
>
> > where they were mentioning a fake "operator", an artifact of how the C
> > language is interpreted, that looked like it caused the value of a
> > variable to "go to" another. Namely, "x --> 0" in the code was just
> > "x-- > 0", giving it the appearance of having the effect of
> > "incrementing x toward 0". Now, I was wondering: would this be a good
> > idea for a new real operator for the C language? Namely, "a -->
> > b" (and "b <-- a") as real operators that could increment a toward b.
> > Or would it be pretty worthless?
>
> I can give you five reasons why not.
>
> 1. It would be worthless because using it would make your code nonportable to all
>    the compilers which have decided to ignore implementing such a thing.
>    The best feature of C is stability, and the best dialect for that is ISO C90,
>    (with perhaps some very judicious use of new-fangled libraries from C99 and C11.)
>

So does this mean using C99, etc. is bad, then? If not, then how come
more compiler
developers would implement C99, etc. stuff and not --> if --> became a
real part of the
C language?

> 2. The --> and <-- syntax has an existing meaning. It is tokenized as {--}{>}
>    and {<}{--}.  The expression a-->b is already valid C. It means (a--) > (b).
>    In other words, decrement a, and test whether the prior value is greater than b.
>    So your proposal horribly breaks the current language, making it a complete
>    nonstarter.
>

So make it ==> and <==.

> 3. Not having b <-- a, you have to write something like a = (a < b) ? a + 1 : a - 1;
>    This is not a big deal and you can hide it behind a macro, except that it evaluates
>    a twice:
>
>      #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)
>
>    See? You can implement the operator in C already, just not with the syntax you want,
>    and with a small semantic concession. But this means that the --> operator
>    does not express anything which cannot be expressed already, it just makes a
>    small, incremental semantic improvement over the macro. A small, incremental
>    improvement is harder to justify. Moreover, the syntax that you want breaks
>    the existing syntax (point 2 above), whereas the INCTOWARD macro doesn't.
>

True. But could the compiler optimize it better (e.g. if it's used in
a loop) if it were
a builtin?

> 4. There is no corresponding machine instruction in any popular machine
>    instruction set, so you're not going to get better code by providing an inctoward
>    operator in the language.  And even if there is a single machine instruction
>    for doing (A < B ? A + 1 : A - 1), a compiler just has to recognize this
>    syntax tree pattern, and check a few constraints and then use the
>    instruction. It is not strictly necessary to have a dedicated operator.
>    For instance, some instruction sets have a division instruction which yields both
>    the quotient and the modulus. Compilers recognize code like
>    a = b / c; d = b % c and emit just one division instruction from which the
>    quotient and modulus are obtained for a and d.
>

This is probably one of the best points against this. All other C
operators have some
kind of equivalent machine instruction on most machines, or close
enough. So yes, I'd
admit, this may be a downside.

> 5. A trivial new arithmetic operator is not going to lend expressivity to the C language.
>    And anyway, programmers don't need C to be expressive. By and large they
>    need it to be a "portable assembler". If you want expressivity, you invent
>    another programming language and then interpret it with C, or compile it to C.
>    That language can easily have an A <-- B operator, which expands into
>    the appropriate C (with clean evaluation semantics and everything).

I thought it'd be kind of neat, but maybe it isn't really necessary.
I'd wonder, how
often does it come up that you need to increment one variable "toward"
another, i.e.
make one "go to" another? Though I haven't programmed a big diversity
of things,
it dosn't seem to be super often, unlike conventional increments.

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

#26231

On 12/09/2012 00:25, mike3 wrote:
> On Sep 11, 1:24 pm, Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2012-09-10, mike3 <mike4...@yahoo.com> wrote:
>>
>>> Hi.
>>
>>> I was wondering about this. I saw this posting on this site:
>>
>>> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-o...
>>
>>>
>>>
where they were mentioning a fake "operator", an artifact of how the C
>>> language is interpreted, that looked like it caused the value of
>>> a variable to "go to" another. Namely, "x --> 0" in the code was
>>> just "x-- > 0", giving it the appearance of having the effect of
>>> "incrementing x toward 0". Now, I was wondering: would this be a
>>> good idea for a new real operator for the C language? Namely, "a
>>> --> b" (and "b <-- a") as real operators that could increment a
>>> toward b. Or would it be pretty worthless?
>>
>> I can give you five reasons why not.
>>
>> 1. It would be worthless because using it would make your code
>> nonportable to all the compilers which have decided to ignore
>> implementing such a thing. The best feature of C is stability, and
>> the best dialect for that is ISO C90, (with perhaps some very
>> judicious use of new-fangled libraries from C99 and C11.)
>>
>
> So does this mean using C99, etc. is bad, then? If not, then how
> come more compiler developers would implement C99, etc. stuff and not
> --> if --> became a real part of the C language?
>

People (compiler users, compiler writers, and language standards 
committees) do move towards newer language features.  But there is a 
very high threshold before new features are added to the language.  Just 
look at the recent discussions about adding C features to C++ or C++ 
features to C - this is a tough processes even when the features are of 
obvious benefit to users, are already implemented by the compilers, are 
familiar to many users (since many people are fluent in C /and/ C++), 
and are documented in similar types of standards.

So for a nonsensical operator with poorly specified semantics, rare use 
cases, and a syntax that conflicts with existing standards, I would not 
be optimistic...

>> 2. The --> and <-- syntax has an existing meaning. It is tokenized
>> as {--}{>} and {<}{--}.  The expression a-->b is already valid C.
>> It means (a--) > (b). In other words, decrement a, and test whether
>> the prior value is greater than b. So your proposal horribly breaks
>> the current language, making it a complete nonstarter.
>>
>
> So make it ==> and <==.
>
>> 3. Not having b <-- a, you have to write something like a = (a < b)
>> ? a + 1 : a - 1; This is not a big deal and you can hide it behind
>> a macro, except that it evaluates a twice:
>>
>> #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)
>>
>> See? You can implement the operator in C already, just not with the
>> syntax you want, and with a small semantic concession. But this
>> means that the --> operator does not express anything which cannot
>> be expressed already, it just makes a small, incremental semantic
>> improvement over the macro. A small, incremental improvement is
>> harder to justify. Moreover, the syntax that you want breaks the
>> existing syntax (point 2 above), whereas the INCTOWARD macro
>> doesn't.
>>
>
> True. But could the compiler optimize it better (e.g. if it's used
> in a loop) if it were a builtin?

Why do you think that?  I don't know what you mean by "the" compiler 
here, but many C compilers are very good at optimising, and they don't 
need builtins to do it.  In this particular case, I'd expect a compiler 
to produce better code with macro version - in many cases, a compiler 
could hoist the initial comparison to the top of the loop, statically 
identify the result of the comparison, and replace the inner loop with a 
simple ++ or -- and comparison.

And in general, /if/ there were significant use cases for such a 
construction, and /if/ there were significant gains to be made by 
treating it specially, then compilers could include the pattern in the 
pattern matching machinery and optimise specifically for it.

>
>> 4. There is no corresponding machine instruction in any popular
>> machine instruction set, so you're not going to get better code by
>> providing an inctoward operator in the language.  And even if there
>> is a single machine instruction for doing (A < B ? A + 1 : A - 1),
>> a compiler just has to recognize this syntax tree pattern, and
>> check a few constraints and then use the instruction. It is not
>> strictly necessary to have a dedicated operator. For instance, some
>> instruction sets have a division instruction which yields both the
>> quotient and the modulus. Compilers recognize code like a = b / c;
>> d = b % c and emit just one division instruction from which the
>> quotient and modulus are obtained for a and d.
>>
>
> This is probably one of the best points against this. All other C
> operators have some kind of equivalent machine instruction on most
> machines, or close enough. So yes, I'd admit, this may be a
> downside.

No, many operators do not equate to a machine instruction on most 
targets.  There are a few cpu targets that have hardware support for 
things like division - a great many cannot even do a 16-bit increment in 
a single instruction.  There are also many machine instructions that do 
not correspond to a single C construct - the most obvious one being that 
on most targets, a "comparison" operation gives flags for greater than, 
less than, equal to, and combinations thereof, while in C you can only 
test for one at a time.  It is up to compilers to spot patterns like "if 
(a > b) { .. } else if (a < b) { ... }" and generate a single comparison.

Arguing based on target machine instructions and/or compiler 
implementations is best done when you have experience of a wide range of 
target architectures and of compiler functionality.

>
>> 5. A trivial new arithmetic operator is not going to lend
>> expressivity to the C language. And anyway, programmers don't need
>> C to be expressive. By and large they need it to be a "portable
>> assembler". If you want expressivity, you invent another
>> programming language and then interpret it with C, or compile it to
>> C. That language can easily have an A <-- B operator, which expands
>> into the appropriate C (with clean evaluation semantics and
>> everything).
>
> I thought it'd be kind of neat, but maybe it isn't really necessary.
> I'd wonder, how often does it come up that you need to increment one
> variable "toward" another, i.e. make one "go to" another? Though I
> haven't programmed a big diversity of things, it dosn't seem to be
> super often, unlike conventional increments.
>

I just cannot see a point in this operator.  The nearest I can think of 
that would actually be useful would be "if (x) x--;".

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

#26243

On Sep 12, 1:41 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 12/09/2012 00:25, mike3 wrote:> On Sep 11, 1:24 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> >> On 2012-09-10, mike3 <mike4...@yahoo.com> wrote:
>
> >>> Hi.
>
> >>> I was wondering about this. I saw this posting on this site:
>
> >>>http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-o...
>
> where they were mentioning a fake "operator", an artifact of how the C
>
>
>
> >>> language is interpreted, that looked like it caused the value of
> >>> a variable to "go to" another. Namely, "x --> 0" in the code was
> >>> just "x-- > 0", giving it the appearance of having the effect of
> >>> "incrementing x toward 0". Now, I was wondering: would this be a
> >>> good idea for a new real operator for the C language? Namely, "a
> >>> --> b" (and "b <-- a") as real operators that could increment a
> >>> toward b. Or would it be pretty worthless?
>
> >> I can give you five reasons why not.
>
> >> 1. It would be worthless because using it would make your code
> >> nonportable to all the compilers which have decided to ignore
> >> implementing such a thing. The best feature of C is stability, and
> >> the best dialect for that is ISO C90, (with perhaps some very
> >> judicious use of new-fangled libraries from C99 and C11.)
>
> > So does this mean using C99, etc. is bad, then? If not, then how
> > come more compiler developers would implement C99, etc. stuff and not
> > --> if --> became a real part of the C language?
>
> People (compiler users, compiler writers, and language standards
> committees) do move towards newer language features.  But there is a
> very high threshold before new features are added to the language.  Just
> look at the recent discussions about adding C features to C++ or C++
> features to C - this is a tough processes even when the features are of
> obvious benefit to users, are already implemented by the compilers, are
> familiar to many users (since many people are fluent in C /and/ C++),
> and are documented in similar types of standards.
>
> So for a nonsensical operator with poorly specified semantics, rare use
> cases, and a syntax that conflicts with existing standards, I would not
> be optimistic...
>

What would need to be specified with regards to the semantics? And I
also
proposed an alternative symbol for the operator here. But I suppose
the
ultimate problem is going to be that of "rare use case" -- and there
ain't
nothin' anyone can do about that... In other words, there doesn't
appear
to be much hope for this operator... <sniff>

>
>
> >> 2. The --> and <-- syntax has an existing meaning. It is tokenized
> >> as {--}{>} and {<}{--}.  The expression a-->b is already valid C.
> >> It means (a--) > (b). In other words, decrement a, and test whether
> >> the prior value is greater than b. So your proposal horribly breaks
> >> the current language, making it a complete nonstarter.
>
> > So make it ==> and <==.
>
> >> 3. Not having b <-- a, you have to write something like a = (a < b)
> >> ? a + 1 : a - 1; This is not a big deal and you can hide it behind
> >> a macro, except that it evaluates a twice:
>
> >> #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)
>
> >> See? You can implement the operator in C already, just not with the
> >> syntax you want, and with a small semantic concession. But this
> >> means that the --> operator does not express anything which cannot
> >> be expressed already, it just makes a small, incremental semantic
> >> improvement over the macro. A small, incremental improvement is
> >> harder to justify. Moreover, the syntax that you want breaks the
> >> existing syntax (point 2 above), whereas the INCTOWARD macro
> >> doesn't.
>
> > True. But could the compiler optimize it better (e.g. if it's used
> > in a loop) if it were a builtin?
>
> Why do you think that?  I don't know what you mean by "the" compiler
> here, but many C compilers are very good at optimising, and they don't
> need builtins to do it.  In this particular case, I'd expect a compiler
> to produce better code with macro version - in many cases, a compiler
> could hoist the initial comparison to the top of the loop, statically
> identify the result of the comparison, and replace the inner loop with a
> simple ++ or -- and comparison.
>
> And in general, /if/ there were significant use cases for such a
> construction, and /if/ there were significant gains to be made by
> treating it specially, then compilers could include the pattern in the
> pattern matching machinery and optimise specifically for it.
>

I was just thinking that maybe a builtin could help provide better
"hints"
to the compiler, but I guess it isn't really necessary...

>
>
>
>
> >> 4. There is no corresponding machine instruction in any popular
> >> machine instruction set, so you're not going to get better code by
> >> providing an inctoward operator in the language.  And even if there
> >> is a single machine instruction for doing (A < B ? A + 1 : A - 1),
> >> a compiler just has to recognize this syntax tree pattern, and
> >> check a few constraints and then use the instruction. It is not
> >> strictly necessary to have a dedicated operator. For instance, some
> >> instruction sets have a division instruction which yields both the
> >> quotient and the modulus. Compilers recognize code like a = b / c;
> >> d = b % c and emit just one division instruction from which the
> >> quotient and modulus are obtained for a and d.
>
> > This is probably one of the best points against this. All other C
> > operators have some kind of equivalent machine instruction on most
> > machines, or close enough. So yes, I'd admit, this may be a
> > downside.
>
> No, many operators do not equate to a machine instruction on most
> targets.  There are a few cpu targets that have hardware support for
> things like division - a great many cannot even do a 16-bit increment in
> a single instruction.  There are also many machine instructions that do
> not correspond to a single C construct - the most obvious one being that
> on most targets, a "comparison" operation gives flags for greater than,
> less than, equal to, and combinations thereof, while in C you can only
> test for one at a time.  It is up to compilers to spot patterns like "if
> (a > b) { .. } else if (a < b) { ... }" and generate a single comparison.
>
> Arguing based on target machine instructions and/or compiler
> implementations is best done when you have experience of a wide range of
> target architectures and of compiler functionality.
>

So in light of all this, is the machine-instruction argument I
originally
responded to really worth anything, then?

>
>
>
>
> >> 5. A trivial new arithmetic operator is not going to lend
> >> expressivity to the C language. And anyway, programmers don't need
> >> C to be expressive. By and large they need it to be a "portable
> >> assembler". If you want expressivity, you invent another
> >> programming language and then interpret it with C, or compile it to
> >> C. That language can easily have an A <-- B operator, which expands
> >> into the appropriate C (with clean evaluation semantics and
> >> everything).
>
> > I thought it'd be kind of neat, but maybe it isn't really necessary.
> > I'd wonder, how often does it come up that you need to increment one
> > variable "toward" another, i.e. make one "go to" another? Though I
> > haven't programmed a big diversity of things, it dosn't seem to be
> > super often, unlike conventional increments.
>
> I just cannot see a point in this operator.  The nearest I can think of
> that would actually be useful would be "if (x) x--;".

And I guess that's the biggest problem here -- there just really isn't
much point to this operator.

Oh well...

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

#26290

On 12/09/2012 17:33, mike3 wrote:
> On Sep 12, 1:41 am, David Brown
> <da...@westcontrol.removethisbit.com> wrote:
>> On 12/09/2012 00:25, mike3 wrote:> On Sep 11, 1:24 pm, Kaz Kylheku
>> <k...@kylheku.com> wrote:
>>>> On 2012-09-10, mike3 <mike4...@yahoo.com> wrote:
<snip>
>>> So does this mean using C99, etc. is bad, then? If not, then how
>>> come more compiler developers would implement C99, etc. stuff and
>>> not --> if --> became a real part of the C language?
>>
>> People (compiler users, compiler writers, and language standards
>> committees) do move towards newer language features.  But there is
>> a very high threshold before new features are added to the
>> language.  Just look at the recent discussions about adding C
>> features to C++ or C++ features to C - this is a tough processes
>> even when the features are of obvious benefit to users, are already
>> implemented by the compilers, are familiar to many users (since
>> many people are fluent in C /and/ C++), and are documented in
>> similar types of standards.
>>
>> So for a nonsensical operator with poorly specified semantics, rare
>> use cases, and a syntax that conflicts with existing standards, I
>> would not be optimistic...
>>
>
> What would need to be specified with regards to the semantics? And I
> also proposed an alternative symbol for the operator here. But I
> suppose the ultimate problem is going to be that of "rare use case"
> -- and there ain't nothin' anyone can do about that... In other
> words, there doesn't appear to be much hope for this operator...
> <sniff>
>

That's correct.  As you say, the syntax conflict can be avoided by
changing the symbol (though "==>" would stand out as odd in C), and the
semantic specification could easily be tightened (by saying what "a -->
b" means when a and b are the same).  But in the end, it is a weird
symbol which would not have obvious meaning to users, and it would very
seldom be useful in real-world code.

<snip>

>>> True. But could the compiler optimize it better (e.g. if it's
>>> used in a loop) if it were a builtin?
>>
>> Why do you think that?  I don't know what you mean by "the"
>> compiler here, but many C compilers are very good at optimising,
>> and they don't need builtins to do it.  In this particular case,
>> I'd expect a compiler to produce better code with macro version -
>> in many cases, a compiler could hoist the initial comparison to the
>> top of the loop, statically identify the result of the comparison,
>> and replace the inner loop with a simple ++ or -- and comparison.
>>
>> And in general, /if/ there were significant use cases for such a
>> construction, and /if/ there were significant gains to be made by
>> treating it specially, then compilers could include the pattern in
>> the pattern matching machinery and optimise specifically for it.
>>
>
> I was just thinking that maybe a builtin could help provide better
> "hints" to the compiler, but I guess it isn't really necessary...
>

Compiler developers seem to manage quite well at optimising general code!

Of course, there is another alternative, that would be far more 
realistic (if the operations were something people actually needed) - 
rather than having a new symbol, compilers could provide it as a builtin 
function.  For gcc, for example, it would not be too hard to add a new 
"__builtin__inctoward" function in the same manner that there are 
builtins for other operations, such as "__builtin_clz" for a "count 
leading zeros" operation:

<http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html>

It is very common for compilers to have such builtins, or "intrinsics", 
when the target supports particular operations that cannot otherwise be 
easily expressed in C.

Now all you need to do is find a target cpu that supports your "-->" 
operation!


>>
>>
>>
>>
>>>> 4. There is no corresponding machine instruction in any
>>>> popular machine instruction set, so you're not going to get
>>>> better code by providing an inctoward operator in the language.
>>>> And even if there is a single machine instruction for doing (A
>>>> < B ? A + 1 : A - 1), a compiler just has to recognize this
>>>> syntax tree pattern, and check a few constraints and then use
>>>> the instruction. It is not strictly necessary to have a
>>>> dedicated operator. For instance, some instruction sets have a
>>>> division instruction which yields both the quotient and the
>>>> modulus. Compilers recognize code like a = b / c; d = b % c and
>>>> emit just one division instruction from which the quotient and
>>>> modulus are obtained for a and d.
>>
>>> This is probably one of the best points against this. All other
>>> C operators have some kind of equivalent machine instruction on
>>> most machines, or close enough. So yes, I'd admit, this may be a
>>> downside.
>>
>> No, many operators do not equate to a machine instruction on most
>> targets.  There are a few cpu targets that have hardware support
>> for things like division - a great many cannot even do a 16-bit
>> increment in a single instruction.  There are also many machine
>> instructions that do not correspond to a single C construct - the
>> most obvious one being that on most targets, a "comparison"
>> operation gives flags for greater than, less than, equal to, and
>> combinations thereof, while in C you can only test for one at a
>> time.  It is up to compilers to spot patterns like "if (a > b) { ..
>> } else if (a < b) { ... }" and generate a single comparison.
>>
>> Arguing based on target machine instructions and/or compiler
>> implementations is best done when you have experience of a wide
>> range of target architectures and of compiler functionality.
>>
>
> So in light of all this, is the machine-instruction argument I
> originally responded to really worth anything, then?

Not in this case, I think.  But ff you had been arguing for a "*+=" 
operator defined such that "a *+= b : c" means "a += b*c without regard 
to IEEE rules on ordering or NaNs", then the machine-instruction 
argument would carry a lot of weight.

>
>>
>>
>>
>>
>>>> 5. A trivial new arithmetic operator is not going to lend
>>>> expressivity to the C language. And anyway, programmers don't
>>>> need C to be expressive. By and large they need it to be a
>>>> "portable assembler". If you want expressivity, you invent
>>>> another programming language and then interpret it with C, or
>>>> compile it to C. That language can easily have an A <-- B
>>>> operator, which expands into the appropriate C (with clean
>>>> evaluation semantics and everything).
>>
>>> I thought it'd be kind of neat, but maybe it isn't really
>>> necessary. I'd wonder, how often does it come up that you need to
>>> increment one variable "toward" another, i.e. make one "go to"
>>> another? Though I haven't programmed a big diversity of things,
>>> it dosn't seem to be super often, unlike conventional
>>> increments.
>>
>> I just cannot see a point in this operator.  The nearest I can
>> think of that would actually be useful would be "if (x) x--;".
>
> And I guess that's the biggest problem here -- there just really
> isn't much point to this operator.
>
> Oh well...
>

Daft ideas can help inspire good ideas and become a source of progress, 
so there is no harm in speculating.

There /are/ times when it is useful to have a language that is like C, 
but has a few syntax variations or additional features (look at XMOS 
"XC" if you are interested).  But these are niche tools for particular 
targets or applications, and no one imagines that these additions will 
get moved into the C language proper.

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

#26246

In article <20120911115303.248@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
>
>I can give you five reasons why not.
>
>1. It would be worthless because using it would make your code nonportable to all
>   the compilers which have decided to ignore implementing such a thing.
>   The best feature of C is stability, and the best dialect for that is ISO C90,
>   (with perhaps some very judicious use of new-fangled libraries from C99 and C11.)

This one alone is sufficient.  C has managed to evolve into the most portable
language there is, primarily because of its stability.

(Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
it's too late for even those.)

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

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

#26275

On Sep 12, 11:43 am, f...@rahul.net (Edward A. Falk) wrote:
> In article <20120911115303....@kylheku.com>,
> Kaz Kylheku  <k...@kylheku.com> wrote:
>
>
>
> >I can give you five reasons why not.
>
> >1. It would be worthless because using it would make your code nonportable to all
> >   the compilers which have decided to ignore implementing such a thing.
> >   The best feature of C is stability, and the best dialect for that is ISO C90,
> >   (with perhaps some very judicious use of new-fangled libraries from C99 and C11.)
>
> This one alone is sufficient.  C has managed to evolve into the most portable
> language there is, primarily because of its stability.
>

Also, rarity of usage looks like another good point against this
proposal. I think
I've used pretty much every C operator there is, and yet there are
people here saying
they'd never have used this --> operator in years and years of C
programming.

I'm thinking I should probably put this one to bed...

> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
> it's too late for even those.)
>
> --
>         -Ed Falk, f...@despams.r.us.com
>        http://thespamdiaries.blogspot.com/

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

#26287

On 2012-09-12, Edward A. Falk <falk@rahul.net> wrote:
> This one alone is sufficient.  C has managed to evolve into the most portable
> language there is, primarily because of its stability.
> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
> it's too late for even those.)

<stdlib.h> has abs(), labs(), llabs().

<math.h> has fabs(), fmin(), fmax() for the floatingpoint types.

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

#26294

"Ike Naar" <ike@iceland.freeshell.org> wrote in message 
news:slrn3vfsk52vjs.2sc.ike@iceland.freeshell.org...
> On 2012-09-12, Edward A. Falk <falk@rahul.net> wrote:
>> This one alone is sufficient.  C has managed to evolve into the most 
>> portable
>> language there is, primarily because of its stability.
>> (Although I wouldn't mind built-in abs(), min(), and max() functions, I 
>> admit
>> it's too late for even those.)
>
> <stdlib.h> has abs(), labs(), llabs().
>
> <math.h> has fabs(), fmin(), fmax() for the floatingpoint types.

They might be built-in, but they are still just functions with all their 
limitations:

o Not being able to use them in constant expressions
o Having to use different names depending on the exact type of the argument

So there's nothing to stop someone defined their own min()/max() functions, 
except:

o They would not be standard
o They would need min, umin, lmin, lumin, llmin, llumin, and the same for 
max. (You could probably get away with providing only long long versions, 
but there would be a lot of unnecessary promotions.)

If min(), max() were operators, then that would be it; you wouldn't need 
anything else, not even fmin() and fmax().

-- 
Bartc 

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

#26332

בתאריך יום רביעי, 12 בספטמבר 2012 18:43:10 UTC+1, מאת Edward A. Falk:
> In article <20120911115303.248@kylheku.com>,
> 
> 
> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit 
> it's too late for even those.)
> 
You could have |x| syntax. That would look a bit more mathematical. 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web