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

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

Re: Parentheses as operators

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Parentheses as operators Keith Thompson <kst-u@mib.org> - 2015-08-17 13:17 -0700
    Re: Parentheses as operators Richard Heathfield <rjh@cpax.org.uk> - 2015-08-17 20:57 +0100
      Re: Parentheses as operators Keith Thompson <kst-u@mib.org> - 2015-08-17 14:36 -0700
      Re: Parentheses as operators Keith Thompson <kst-u@mib.org> - 2015-08-17 14:40 -0700

#67618 — Re: Parentheses as operators

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>   To me, an operator is a sequence of fixed tokens and gaps
>   that yields an expression, when expressions are inserted
>   into the gaps. For example:
[SNIP]
>   But the parentheses usually do not count as an operator:
[SNIP]
>   Would it be wrong to call the parentheses an »operator«?

Depends on what you mean by "wrong".

The standard doesn't seem to have a definition of "operator", though I
don't see any wording that refers to parentheses as an operator.

Function calls are described in the "Postfix operators" section, but I
don't think there's any reference to a "function call operator".  If a
function call were an operator, its operands would be the
pointer-to-function expression and the arguments.  It's hard to describe
how many "operands" a function call has, and the standard doesn't try.

N1570 6.5p1 says:

    An *expression* is a sequence of operators and operands that
    specifies computation of a value, or that designates an object or a
    function, or that generates side effects, or that performs a
    combination thereof.

which is not accurate, since `42` is clearly an expression, but it has
no operators and therefore no operands.

    The value computations of the operands of an operator are sequenced
    before the value computation of the result of the operator.

That could apply as easily to `(expr)` as to `+expr`, as could the rest
of 6.5.

It seems that the standard doesn't refer to parentheses as an operator,
but it could have done so without loss of consistency or accuracy.

Call it an operator if you like -- but don't expect everyone to agree
with your usage.

-- 
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] | [next] | [standalone]

#67619

On 17/08/2015 21:17, Keith Thompson wrote:

<snip>

> N1570 6.5p1 says:
>
>      An *expression* is a sequence of operators and operands that
>      specifies computation of a value, or that designates an object or a
>      function, or that generates side effects, or that performs a
>      combination thereof.
>
> which is not accurate, since `42` is clearly an expression, but it has
> no operators and therefore no operands.

It could be argued that it is a sequence of 0 operators and 1 operand 
that specifies the computation of the value 42.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#67631

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 17/08/2015 21:17, Keith Thompson wrote:
>
> <snip>
>
>> N1570 6.5p1 says:
>>
>>      An *expression* is a sequence of operators and operands that
>>      specifies computation of a value, or that designates an object or a
>>      function, or that generates side effects, or that performs a
>>      combination thereof.
>>
>> which is not accurate, since `42` is clearly an expression, but it has
>> no operators and therefore no operands.
>
> It could be argued that it is a sequence of 0 operators and 1 operand 
> that specifies the computation of the value 42.
>
> <snip>

It could -- but not correctly.

N1570 6.4.6p2 defines the word "operand"

    A punctuator is a symbol that has independent syntactic and
    semantic significance.  Depending on context, it may specify an
    operation to be performed (which in turn may yield a value or a
    function designator, produce a side effect, or some combination
    thereof) in which case it is known as an *operator* (other forms
    of operator also exist in some contexts).

I previously says that the standard doesn't define the word "operator".
I was only partially correct; this is a definition, but explicitly an
incomplete one.  It *could* leave the door open to defining parentheses
an an "operator", but if the standard does so I haven't found it.

    An *operand* is an entity on which an operator acts.

Which implies that there can be no operand without an operator acting on
it.

42 certainly *can* be an operand, but in a case like:

    42;

it isn't.

(This is just a bit of sloppy wording.  The grammar defines "expression"
unambiguously, and 42 is clearly *intended* to be an expression; the
definition in 6.5p1 just doesn't capture the intent properly.)

-- 
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]

#67632

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>>On 17/08/2015 21:17, Keith Thompson wrote:
>><snip>
>>> N1570 6.5p1 says:
>>>      An *expression* is a sequence of operators and operands that
>>>      specifies computation of a value, or that designates an object or a
>>>      function, or that generates side effects, or that performs a
>>>      combination thereof.
>>> which is not accurate, since `42` is clearly an expression, but it has
>>> no operators and therefore no operands.
>>It could be argued that it is a sequence of 0 operators and 1 operand 
>>that specifies the computation of the value 42.
>
>   In
>
> sizeof( double )
>
>   , by the above, »double« seems to be an operand, but it is
>   not an expression itself. So then, operands are not always
>   expressions.

The operand is not `double`, but `(double)`, and the operator is
`sizeof`.

>   I'd only call the »sizeof« as in
>
> sizeof 19
>
>   an »operator«, while I'd call expressions such as:
>
> ( double )2
>
>   and
>
> sizeof( double )
>
>   to be »special forms«. But »special form« is no C term IIRC,
>   it might stem from LISP.

I agree that that would be a more consistent description, and one that
I'd prefer, but it's not what the standard says.

>   In the case of a cast ("cast operator"), I always wondered
>   whether
>
> ( double )2
>
>   is a binary operator with »double« and »2« as operands,
>   or whether it is a unary operator with »( double )« being
>   the operator and »2« being its sole operand.

Neither.  `(double)` is a cast operator, and `(double)2` is a
cast-expression.

The phrase "unary operator" doesn't just mean an operator with one
operand (postfix ++ takes one operand but is not a unary operator), nor
does "binary operator" just mean an operator with two operands ([] takes
two operands but is not a binary operator).  Both are specific forms
defined by the grammar.

-- 
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] | [standalone]

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

csiph-web