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

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

Untyped Variables

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

Contents

  Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-07 18:19 -0700
    Re: Untyped Variables Lőrinczy Zsigmond <nospam@for.me> - 2015-08-08 06:53 +0200
    Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 11:09 -0400
      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:09 -0700
        Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 14:24 -0400
      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:54 -0700
        Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:06 -0700
          Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 17:29 -0700
            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 17:52 -0700
              Re: Untyped Variables Ian Collins <ian-news@hotmail.com> - 2015-08-10 12:57 +1200
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:41 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:06 -0700
          Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 19:44 -0400
          Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 20:34 -0400
            Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 02:03 +0000
              Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 22:52 -0400
                Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 04:57 +0000
                  Re: Untyped Variables Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-09 09:58 -0600
                    Re: Untyped Variables Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:54 -0700
                  Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:59 -0400
            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 18:02 -0700
              Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 11:01 -0400
                Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:20 -0400
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:54 -0700
                  Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:20 -0400
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:11 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:15 -0700
                  Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:30 -0400
                    Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:50 -0700
                      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 17:24 -0700
                        Re: Untyped Variables Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:37 +0100
                        Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-12 04:46 +0000
                        Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-12 18:12 -0700
                          Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-13 12:08 -0700
                            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-13 16:25 -0700
                              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-14 10:36 -0700
                        Re: Untyped Variables Bartc <bc@freeuk.com> - 2015-08-14 19:13 +0100
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 07:58 -0700
            Re: Untyped Variables richard@cogsci.ed.ac.uk (Richard Tobin) - 2015-08-10 13:53 +0000
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:29 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:01 -0700
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 17:42 -0700
                    Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 02:56 +0000
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:50 -0700
                Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 01:39 +0100
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 19:03 -0700
                    Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 11:21 +0100
                  Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:37 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#67049

On Saturday, August 8, 2015 at 5:34:12 PM UTC-7, James Kuyper wrote:
> On 08/08/2015 07:06 PM, David Kleinecke wrote:
> ...
> > I haven't been thinking of constraints as part of syntax. ...
> 
> It would be more accurate to say that some constraints constrain the
> syntax. For example (6.4.3p1):
> 
> 
> > 1     universal-character-name:
> >              \u hex-quad
> >              \U hex-quad hex-quad
> >       hex-quad:
> >             hexadecimal-digit hexadecimal-digit
> >                            hexadecimal-digit hexadecimal-digit
> >
> >   Constraints
> > 2 A universal character name shall not specify a character whose short identifier is less than
> >   00A0 other than 0024 ($), 0040 (@), or 0060 ('), nor one in the range D800 through
> >   DFFF inclusive.73)
> 
> In general, the constrained syntax could alternatively have been
> described using only syntax rules. If a constraint was used, it's
> generally because expressing the same idea with syntax rules would have
> made it much more complex. For example:
> 
> universal-character-name:
> 	\u ucn-hex-quad
> 	\U hex-quad hex-quad
> 
> hex-quad:
> 	hexadecimal-digit hexadecimal-digit
>                       hexadecimal-digit hexadecimal-digit
> 
> ucn-hex-quad:
> 	0 0 2 4
> 	0 0 4 0
> 	0 0 6 0
> 	0 0 a-f hexadecimal-digit
> 	0 one-f hexadecimal-digit hexadecimal-digit
> 	one-c-e-f hexadecimal-digit hexadecimal-digit hexadecimal-digit
> 	D zero-six hexadecimal-digit hexadecimal-digit
> 	D 7 zero-eight hexadecimal-digit
> 	D 7 9 digit
> 
> a-f: One of
> 	A B C D E F
> 
> one-f: One of
>         1 2 3 4 5 6 7 8 9 0 A B C D E F
> 
> one-c-e-f: One of
> 	1 2 3 4 5 6 7 8 9 A B C E F
> 
> zero-six: One of
> 	0 1 2 3 4 5 6
> 
> zero-eight: One of
> 	0 1 2 3 4 5 6 7 8
> 	
> Which is easier to understand - the constrained syntax rules, or the
> alternative expressed purely in the form of syntax rules?
> Note: if there's any error in my syntax rules for ucn-hex-quad, I won't
> be surprised. That merely emphasizes the advantages of using a
> constraint rather syntax rules for this kind of thing.

I, as always am only talking C90. But I don't see why the syntax you
quote can't pass the details to semantics.

The general strategy in C is to over-generate parses and then filter 
them semantically. Many of the semantic filters can also be done be
done syntactically. IMO this is the correct strategy but it is not
also followed. For example, "cast-expression" is an unfortunate way of introducing a semantic filter into syntax.

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

#67068

On 08/09/2015 09:02 PM, David Kleinecke wrote:
> On Saturday, August 8, 2015 at 5:34:12 PM UTC-7, James Kuyper wrote:
>> On 08/08/2015 07:06 PM, David Kleinecke wrote:
>> ...
>>> I haven't been thinking of constraints as part of syntax. ...
>>
>> It would be more accurate to say that some constraints constrain the
>> syntax. For example (6.4.3p1):
>>
>>
>>> 1     universal-character-name:
>>>              \u hex-quad
>>>              \U hex-quad hex-quad
>>>       hex-quad:
>>>             hexadecimal-digit hexadecimal-digit
>>>                            hexadecimal-digit hexadecimal-digit
>>>
>>>   Constraints
>>> 2 A universal character name shall not specify a character whose short identifier is less than
>>>   00A0 other than 0024 ($), 0040 (@), or 0060 ('), nor one in the range D800 through
>>>   DFFF inclusive.73)
>>
>> In general, the constrained syntax could alternatively have been
>> described using only syntax rules. If a constraint was used, it's
>> generally because expressing the same idea with syntax rules would have
>> made it much more complex. For example:
...
> I, as always am only talking C90.

I gave the first example I could find of a semantic constraint. I was
only intending it as a proof of principle.

If you want to restrict your attention to constraints that were present
in C90, look for the C90 equivalent of the following C2011 constraint:
"At most, one storage-class specifier may be given in the declaration
specifiers in a declaration ..." (6.7.1p2). Something like that should
be present in C90, possibly with slightly different wording or a
different section number.

That is a purely syntactic constraint, but because the standard allows
storage-class-specifiers to be mixed freely with the other kinds of
declaration-specifiers (6.7p1), I don't see any way to impose that same
requirement using only syntax rules of the form used by the standard -
possibly I'm being insufficiently clever.

> But I don't see why the syntax you
> quote can't pass the details to semantics.

Possibly - but that's not relevant to my point - which is that this is
is, as currently written, a purely syntactic constraint.
-- 
James Kuyper

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

#67078

On 08/10/2015 11:01 AM, James Kuyper wrote:
...
> I gave the first example I could find of a semantic constraint. I was

Correction: semantic => syntactic

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

#67093

On Monday, August 10, 2015 at 8:02:10 AM UTC-7, James Kuyper wrote:
> On 08/09/2015 09:02 PM, David Kleinecke wrote:
> > On Saturday, August 8, 2015 at 5:34:12 PM UTC-7, James Kuyper wrote:
> >> On 08/08/2015 07:06 PM, David Kleinecke wrote:
> >> ...
> >>> I haven't been thinking of constraints as part of syntax. ...
> >>
> >> It would be more accurate to say that some constraints constrain the
> >> syntax. For example (6.4.3p1):
> >>
> >>
> >>> 1     universal-character-name:
> >>>              \u hex-quad
> >>>              \U hex-quad hex-quad
> >>>       hex-quad:
> >>>             hexadecimal-digit hexadecimal-digit
> >>>                            hexadecimal-digit hexadecimal-digit
> >>>
> >>>   Constraints
> >>> 2 A universal character name shall not specify a character whose short identifier is less than
> >>>   00A0 other than 0024 ($), 0040 (@), or 0060 ('), nor one in the range D800 through
> >>>   DFFF inclusive.73)
> >>
> >> In general, the constrained syntax could alternatively have been
> >> described using only syntax rules. If a constraint was used, it's
> >> generally because expressing the same idea with syntax rules would have
> >> made it much more complex. For example:
> ...
> > I, as always am only talking C90.
> 
> I gave the first example I could find of a semantic constraint. I was
> only intending it as a proof of principle.
> 
> If you want to restrict your attention to constraints that were present
> in C90, look for the C90 equivalent of the following C2011 constraint:
> "At most, one storage-class specifier may be given in the declaration
> specifiers in a declaration ..." (6.7.1p2). Something like that should
> be present in C90, possibly with slightly different wording or a
> different section number.
 
The constraint is there. I just consider it a semantic constraint rather
than a syntactic one.

> That is a purely syntactic constraint, but because the standard allows
> storage-class-specifiers to be mixed freely with the other kinds of
> declaration-specifiers (6.7p1), I don't see any way to impose that same
> requirement using only syntax rules of the form used by the standard -
> possibly I'm being insufficiently clever.
> 
> > But I don't see why the syntax you
> > quote can't pass the details to semantics.
> 
> Possibly - but that's not relevant to my point - which is that this is
> is, as currently written, a purely syntactic constraint.

You appear to have a a definition of "syntactic" in mind that allows
you to declare it a "purely syntactic constraint" Are you willing to
share that definition? 

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

#67103

On 08/10/2015 07:54 PM, David Kleinecke wrote:
> On Monday, August 10, 2015 at 8:02:10 AM UTC-7, James Kuyper wrote:
>> On 08/09/2015 09:02 PM, David Kleinecke wrote:
>>> On Saturday, August 8, 2015 at 5:34:12 PM UTC-7, James Kuyper wrote:
>>>> On 08/08/2015 07:06 PM, David Kleinecke wrote:
>>>> ...
>>>>> I haven't been thinking of constraints as part of syntax. ...
>>>>
>>>> It would be more accurate to say that some constraints constrain the
>>>> syntax. For example (6.4.3p1):
>>>>
>>>>
>>>>> 1     universal-character-name:
>>>>>              \u hex-quad
>>>>>              \U hex-quad hex-quad
>>>>>       hex-quad:
>>>>>             hexadecimal-digit hexadecimal-digit
>>>>>                            hexadecimal-digit hexadecimal-digit
>>>>>
>>>>>   Constraints
>>>>> 2 A universal character name shall not specify a character whose short identifier is less than
>>>>>   00A0 other than 0024 ($), 0040 (@), or 0060 ('), nor one in the range D800 through
>>>>>   DFFF inclusive.73)
>>>>
>>>> In general, the constrained syntax could alternatively have been
>>>> described using only syntax rules. If a constraint was used, it's
>>>> generally because expressing the same idea with syntax rules would have
>>>> made it much more complex. For example:
>> ...
>>> I, as always am only talking C90.
>>
>> I gave the first example I could find of a semantic constraint. I was
>> only intending it as a proof of principle.
>>
>> If you want to restrict your attention to constraints that were present
>> in C90, look for the C90 equivalent of the following C2011 constraint:
>> "At most, one storage-class specifier may be given in the declaration
>> specifiers in a declaration ..." (6.7.1p2). Something like that should
>> be present in C90, possibly with slightly different wording or a
>> different section number.
>  
> The constraint is there. I just consider it a semantic constraint rather
> than a syntactic one.

In line with your question down below, let me ask you what definitions
you use for "syntactic" and "semantic" that support that conclusion.

>> That is a purely syntactic constraint, but because the standard allows
>> storage-class-specifiers to be mixed freely with the other kinds of
>> declaration-specifiers (6.7p1), I don't see any way to impose that same
>> requirement using only syntax rules of the form used by the standard -
>> possibly I'm being insufficiently clever.
>>
>>> But I don't see why the syntax you
>>> quote can't pass the details to semantics.
>>
>> Possibly - but that's not relevant to my point - which is that this is
>> is, as currently written, a purely syntactic constraint.
> 
> You appear to have a a definition of "syntactic" in mind that allows
> you to declare it a "purely syntactic constraint" Are you willing to
> share that definition? 

Quoting wikipedia:
"syntax is the set of rules, principles, and processes that govern the
structure of sentences in a given language."

"Semantics ... is the study of meaning. It focuses on the relation
between signifiers, like words, phrases, signs, and symbols, and what
they stand for; their denotation."

In both cases, 6.4.3p1 and 6.7.1p2, the constraint merely imposes
restrictions on the structure of the program, without regard to it's
meaning.

6.4.3p1 makes it a constraint violation to write a UCN containing
certain sequences of hexadecimal digits. hexadecimal digits and UCNs are
purely syntactic constructs, defined in sections labeled "syntax", and
the rule is given in terms of them. The fact that a diagnostic message
is required if your program contains the token "\u0012" is not
intrinsically different from the fact that a diagnostic message is
required if it contains the token $status . The first is ruled out by a
syntactic constraint, the second is ruled out by the fact that $status
doesn't match the form of any type of token permitted by the syntax
rules, but the nature of the restriction is the same.

6.7.1p2 makes it constraint violation to have more than one
storage-class-specifier in a a declaration. Storage class specifiers and
declarations are purely syntactic constructs, defined as such in
sections labeled "Syntax", and the rule is given in terms of them. The
fact that a diagnostic message is required if your program contains the
tokens "typedef extern int eint;" is not fundamentally different from
the fact that a diagnostic message is required for "5 5 + 3". In each
case, there's one more token of a given type than is allowed - the fact
that the first violates a constraint and the second violates syntax
rules doesn't change the fact that it's the syntax that is incorrect.

In contrast, 6.4.4p2 is a semantic constraint: "Each constant shall have
a type and the value of a constant shall be in the range of
representable values for its type." The type and value of a constant are
semantic features, having to do with the meaning of those constants,
which is why they are described in the sections labeled "Semantics":
6.4.4.1p4-6, 6.4.4.2p3-5, 6.4.4.3p2,  6.4.4.4p10-15.
-- 
James Kuyper

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

#67069

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> The general strategy in C is to over-generate parses and then filter
> them semantically. Many of the semantic filters can also be done be
> done syntactically. IMO this is the correct strategy but it is not
> also followed. For example, "cast-expression" is an unfortunate way of
> introducing a semantic filter into syntax.

Can you expand on that point?  A cast-expression is just one of several
kinds of expressions defined in the syntax (primary-expression,
postfix-expression, unary-expression, cast-expression,
multiplicative-expression etc.), part of the scheme used to define
how expressions are parsed.  What is your objection?

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

#67097

On Monday, August 10, 2015 at 8:05:47 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > The general strategy in C is to over-generate parses and then filter
> > them semantically. Many of the semantic filters can also be done be
> > done syntactically. IMO this is the correct strategy but it is not
> > also followed. For example, "cast-expression" is an unfortunate way of
> > introducing a semantic filter into syntax.
> 
> Can you expand on that point?  A cast-expression is just one of several
> kinds of expressions defined in the syntax (primary-expression,
> postfix-expression, unary-expression, cast-expression,
> multiplicative-expression etc.), part of the scheme used to define
> how expressions are parsed.  What is your objection?
 
Of course there is nothing wrong with cast-exprssion. It's just not
elegant. Its effect is to prohibit certain sequences of unary
operators (I think, ++,-- and sizeof followed by a cast). But this
restriction on possible unary sequences can be handled by a (semantic)
constraint more elegantly.

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

#67104

On 08/10/2015 08:15 PM, David Kleinecke wrote:
> On Monday, August 10, 2015 at 8:05:47 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>>> The general strategy in C is to over-generate parses and then filter
>>> them semantically. Many of the semantic filters can also be done be
>>> done syntactically. IMO this is the correct strategy but it is not
>>> also followed. For example, "cast-expression" is an unfortunate way of
>>> introducing a semantic filter into syntax.
>>
>> Can you expand on that point?  A cast-expression is just one of several
>> kinds of expressions defined in the syntax (primary-expression,
>> postfix-expression, unary-expression, cast-expression,
>> multiplicative-expression etc.), part of the scheme used to define
>> how expressions are parsed.  What is your objection?
>  
> Of course there is nothing wrong with cast-exprssion. It's just not
> elegant. Its effect is to prohibit certain sequences of unary
> operators (I think, ++,-- and sizeof followed by a cast). ...

The effect is to define syntax which can be used to explicitly specify
that a type conversion should be performed. That those sequences are
prohibited is not specified by the grammar for "cast-expression" itself;
they are, if anything, more strongly determined by the grammar rules for
the ++, --, and sizeof operators.

> ... But this
> restriction on possible unary sequences can be handled by a (semantic)
> constraint more elegantly.

An explanation of how you would modify the grammar rules to allow such
sequences, and how you would write a constraint to impose those
restrictions semantically, would make it much easier for us to
understand your objection.
-- 
James Kuyper

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

#67142

On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
> On 08/10/2015 08:15 PM, David Kleinecke wrote:
> > On Monday, August 10, 2015 at 8:05:47 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >>> The general strategy in C is to over-generate parses and then filter
> >>> them semantically. Many of the semantic filters can also be done be
> >>> done syntactically. IMO this is the correct strategy but it is not
> >>> also followed. For example, "cast-expression" is an unfortunate way of
> >>> introducing a semantic filter into syntax.
> >>
> >> Can you expand on that point?  A cast-expression is just one of several
> >> kinds of expressions defined in the syntax (primary-expression,
> >> postfix-expression, unary-expression, cast-expression,
> >> multiplicative-expression etc.), part of the scheme used to define
> >> how expressions are parsed.  What is your objection?
> >  
> > Of course there is nothing wrong with cast-exprssion. It's just not
> > elegant. Its effect is to prohibit certain sequences of unary
> > operators (I think, ++,-- and sizeof followed by a cast). ...
> 
> The effect is to define syntax which can be used to explicitly specify
> that a type conversion should be performed. That those sequences are
> prohibited is not specified by the grammar for "cast-expression" itself;
> they are, if anything, more strongly determined by the grammar rules for
> the ++, --, and sizeof operators.
> 
> > ... But this
> > restriction on possible unary sequences can be handled by a (semantic)
> > constraint more elegantly.
> 
> An explanation of how you would modify the grammar rules to allow such
> sequences, and how you would write a constraint to impose those
> restrictions semantically, would make it much easier for us to
> understand your objection.

I've done this before.

I want to define "expression" by the following syntax
   expression = term Infix..
   term = (Prefix ...) Primitive (Suffix ...)  
where "..." means repeat as many tiems as desired and "A B.." means
repeat A separated by B (as in ABABABAB ...). The C syntax is almost
already in that shape except for two points - one of them in the cast
expression and the other the tertiary operator. (The tertiary can be
forced into the right shape by looking at "QUERY expression COLON" as
an Infix).

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

#67148

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
[...]
>> An explanation of how you would modify the grammar rules to allow such
>> sequences, and how you would write a constraint to impose those
>> restrictions semantically, would make it much easier for us to
>> understand your objection.
>
> I've done this before.
>
> I want to define "expression" by the following syntax
>    expression = term Infix..
>    term = (Prefix ...) Primitive (Suffix ...)  
> where "..." means repeat as many tiems as desired and "A B.." means
> repeat A separated by B (as in ABABABAB ...). The C syntax is almost
> already in that shape except for two points - one of them in the cast
> expression and the other the tertiary operator. (The tertiary can be
> forced into the right shape by looking at "QUERY expression COLON" as
> an Infix).

I can read the C grammar and, with some work, determine whether a given
expression is valid and how it's evaluated.

I can't do that with your description above, at least not without
knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".

Is that intended to be the entire grammar for expressions?  Would you
not have separate rules for additive, multiplicative, shift, and so
forth, expressions?

And you haven't said anyting about constraints.  Would the meaning of
`x + y * z` be specified by the grammar (if so, what you've written above
doesn't do that), or by an English semantic description (if so, you
haven't mentioned it)?

Note that if the binding of `x + y * z` isn't defined by the grammar,
the rule saying that it's equivalent to `x + (y * z)` would not be a
constraint; it would be a semantic description.

(BTW, the "?:" operator is commonly called the *ternary* operator,
though its offical name is the conditional operator.)

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

#67151

On 12/08/15 01:24, Keith Thompson wrote:

<snip>

> (BTW, the "?:" operator is commonly called the *ternary* operator,

Not by me, but yes, you're right, although I doubt very much whether 
that custom would persist in languages with more than one ternary 
operator (in the same way that we don't call = *the* binary operator).

For all those of you looking for ideas for the next stupid language, how 
about one where there is only one symbol for an operator, and the 
meaning of the operator /depends on the number of operands/. (C has 
already broken some ground on this idea, but doesn't take it far enough.)

> though its offical name is the conditional operator.)

That's what I commonly call it.

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

#67162

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

(snip)
> (BTW, the "?:" operator is commonly called the *ternary* operator,
> though its offical name is the conditional operator.)

Hmm, it should be called "a ternary operator", but since it is
the only ternary (three operand) operator in C, I suppose it is
the ternary operator, but it is also the conditional operator.

-- glen

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

#67249

On Tuesday, August 11, 2015 at 5:15:52 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
> [...]
> >> An explanation of how you would modify the grammar rules to allow such
> >> sequences, and how you would write a constraint to impose those
> >> restrictions semantically, would make it much easier for us to
> >> understand your objection.
> >
> > I've done this before.
> >
> > I want to define "expression" by the following syntax
> >    expression = term Infix..
> >    term = (Prefix ...) Primitive (Suffix ...)  
> > where "..." means repeat as many tiems as desired and "A B.." means
> > repeat A separated by B (as in ABABABAB ...). The C syntax is almost
> > already in that shape except for two points - one of them in the cast
> > expression and the other the tertiary operator. (The tertiary can be
> > forced into the right shape by looking at "QUERY expression COLON" as
> > an Infix).
> 
> I can read the C grammar and, with some work, determine whether a given
> expression is valid and how it's evaluated.
> 
> I can't do that with your description above, at least not without
> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".

Infix is any token in the set of tokens corresponding to binary 
operators. Prefix is any token is the set of token corresponding
to unary operators. Suffix is better limited to either "++" or "--"
and all the other postfix treated as part of the primitive. Primitive
(before that last change) means what the standard means by primary
expression. It is possible to add embedded expressions (OPEN
expression CLOSE) to the general syntax but the standard leaves thme
as primitives.

The reason why the names are all changed is that imposing a more
general theory of parsing onto C parsing.  

> Is that intended to be the entire grammar for expressions?  Would you
> not have separate rules for additive, multiplicative, shift, and so
> forth, expressions?
 
That's the whole thing.

> And you haven't said anyting about constraints.  Would the meaning of
> `x + y * z` be specified by the grammar (if so, what you've written above
> doesn't do that), or by an English semantic description (if so, you
> haven't mentioned it)?
 
The semantics are quite elaborate but we are only talking syntax
here. 

> Note that if the binding of `x + y * z` isn't defined by the grammar,
> the rule saying that it's equivalent to `x + (y * z)` would not be a
> constraint; it would be a semantic description.

Actually it's a consequence of assigned token precedences and is buried
in the semantics. 

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

#67324

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, August 11, 2015 at 5:15:52 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
>> [...]
>> >> An explanation of how you would modify the grammar rules to allow such
>> >> sequences, and how you would write a constraint to impose those
>> >> restrictions semantically, would make it much easier for us to
>> >> understand your objection.
>> >
>> > I've done this before.
>> >
>> > I want to define "expression" by the following syntax
>> >    expression = term Infix..
>> >    term = (Prefix ...) Primitive (Suffix ...)  
>> > where "..." means repeat as many tiems as desired and "A B.." means
>> > repeat A separated by B (as in ABABABAB ...). The C syntax is almost
>> > already in that shape except for two points - one of them in the cast
>> > expression and the other the tertiary operator. (The tertiary can be
>> > forced into the right shape by looking at "QUERY expression COLON" as
>> > an Infix).
>> 
>> I can read the C grammar and, with some work, determine whether a given
>> expression is valid and how it's evaluated.
>> 
>> I can't do that with your description above, at least not without
>> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".
>
> Infix is any token in the set of tokens corresponding to binary 
> operators. Prefix is any token is the set of token corresponding
> to unary operators. Suffix is better limited to either "++" or "--"
> and all the other postfix treated as part of the primitive. Primitive
> (before that last change) means what the standard means by primary
> expression. It is possible to add embedded expressions (OPEN
> expression CLOSE) to the general syntax but the standard leaves thme
> as primitives.
>
> The reason why the names are all changed is that imposing a more
> general theory of parsing onto C parsing.  
>
>> Is that intended to be the entire grammar for expressions?  Would you
>> not have separate rules for additive, multiplicative, shift, and so
>> forth, expressions?
>  
> That's the whole thing.
>
>> And you haven't said anyting about constraints.  Would the meaning of
>> `x + y * z` be specified by the grammar (if so, what you've written above
>> doesn't do that), or by an English semantic description (if so, you
>> haven't mentioned it)?
>  
> The semantics are quite elaborate but we are only talking syntax
> here. 

C's syntax specifies how operands are associated with operators.  Your
proposed syntax does not.

>> Note that if the binding of `x + y * z` isn't defined by the grammar,
>> the rule saying that it's equivalent to `x + (y * z)` would not be a
>> constraint; it would be a semantic description.
>
> Actually it's a consequence of assigned token precedences and is buried
> in the semantics. 

Which you haven't described.

You're suggesting that C should have a simpler grammar and a (perhaps
substantially) more complicated semantic description for expressions.
That description would be more vulnerable to ambiguities and
misunderstandings that the current scheme.  If it were expressed
in English that's formal enough to avoid any ambiguities, it would
likely be more difficult to understand than the current grammar.

The current scheme has worked well for decades, and makes compiler
writer's jobs easier.  I don't see the benefit of your proposed
replacement.

If you're saying that your scheme is simpler for programmers to
understand, there's no reason you can't *describe* the rules for C
expressions any way you like, such as an operator precedence table
(as long as the desription is actually consistent with 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] | [next] | [standalone]

#67345

On Thursday, August 13, 2015 at 11:44:36 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Tuesday, August 11, 2015 at 5:15:52 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> > On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
> >> [...]
> >> >> An explanation of how you would modify the grammar rules to allow such
> >> >> sequences, and how you would write a constraint to impose those
> >> >> restrictions semantically, would make it much easier for us to
> >> >> understand your objection.
> >> >
> >> > I've done this before.
> >> >
> >> > I want to define "expression" by the following syntax
> >> >    expression = term Infix..
> >> >    term = (Prefix ...) Primitive (Suffix ...)  
> >> > where "..." means repeat as many tiems as desired and "A B.." means
> >> > repeat A separated by B (as in ABABABAB ...). The C syntax is almost
> >> > already in that shape except for two points - one of them in the cast
> >> > expression and the other the tertiary operator. (The tertiary can be
> >> > forced into the right shape by looking at "QUERY expression COLON" as
> >> > an Infix).
> >> 
> >> I can read the C grammar and, with some work, determine whether a given
> >> expression is valid and how it's evaluated.
> >> 
> >> I can't do that with your description above, at least not without
> >> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".
> >
> > Infix is any token in the set of tokens corresponding to binary 
> > operators. Prefix is any token is the set of token corresponding
> > to unary operators. Suffix is better limited to either "++" or "--"
> > and all the other postfix treated as part of the primitive. Primitive
> > (before that last change) means what the standard means by primary
> > expression. It is possible to add embedded expressions (OPEN
> > expression CLOSE) to the general syntax but the standard leaves thme
> > as primitives.
> >
> > The reason why the names are all changed is that imposing a more
> > general theory of parsing onto C parsing.  
> >
> >> Is that intended to be the entire grammar for expressions?  Would you
> >> not have separate rules for additive, multiplicative, shift, and so
> >> forth, expressions?
> >  
> > That's the whole thing.
> >
> >> And you haven't said anyting about constraints.  Would the meaning of
> >> `x + y * z` be specified by the grammar (if so, what you've written above
> >> doesn't do that), or by an English semantic description (if so, you
> >> haven't mentioned it)?
> >  
> > The semantics are quite elaborate but we are only talking syntax
> > here. 
> 
> C's syntax specifies how operands are associated with operators.  Your
> proposed syntax does not.
> 
> >> Note that if the binding of `x + y * z` isn't defined by the grammar,
> >> the rule saying that it's equivalent to `x + (y * z)` would not be a
> >> constraint; it would be a semantic description.
> >
> > Actually it's a consequence of assigned token precedences and is buried
> > in the semantics. 
> 
> Which you haven't described.

OK each infix has two precednces - left and right. Each prefix has a
left precedence. Suffixes has right precedences. There are two stacks -
one for prefixes and one for data. Starting from the beginning - read 
a token. (1) If it a prefixs push it on the stack (2) If it is a 
primitive hold is a "the value". (3) If it is suffix or infix there 
is an error. Note that tokens like MINUS or STAR can be both prefixes
and infixes and here the prefix version is assumed. Repeat until a value
is found. Read one more token. (1) If it is a suffix compare its right
precedence to the top of the prefix stack and successively code applying
the prefix to the value until the top of the stack has less precedence
than the suffix and then apply the suffix to the value. (2) If it is an
infix handle the stack the same way but instead of applying push the 
infix onto the prefix stack and the value onto the value stack. (3) If it
is any other token you have reached the end of the expression and you
successively pop off prefixes until you get the final value. After (2)
you repeat from the beginning. After (1) only one new token.

I brushed over a couple of minor details but you get the idea.

Any compiler is going to have to do essentially this process even if
the work is not so clearly marked off.   
other token 





> You're suggesting that C should have a simpler grammar and a (perhaps
> substantially) more complicated semantic description for expressions.
> That description would be more vulnerable to ambiguities and
> misunderstandings that the current scheme.  If it were expressed
> in English that's formal enough to avoid any ambiguities, it would
> likely be more difficult to understand than the current grammar.
> 
> The current scheme has worked well for decades, and makes compiler
> writer's jobs easier.  I don't see the benefit of your proposed
> replacement.
> 
> If you're saying that your scheme is simpler for programmers to
> understand, there's no reason you can't *describe* the rules for C
> expressions any way you like, such as an operator precedence table
> (as long as the desription is actually consistent with 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] | [next] | [standalone]

#67408

David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, August 13, 2015 at 11:44:36 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Tuesday, August 11, 2015 at 5:15:52 PM UTC-7, Keith Thompson wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> > On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
>> >> [...]
>> >> >> An explanation of how you would modify the grammar rules to allow such
>> >> >> sequences, and how you would write a constraint to impose those
>> >> >> restrictions semantically, would make it much easier for us to
>> >> >> understand your objection.
>> >> >
>> >> > I've done this before.
>> >> >
>> >> > I want to define "expression" by the following syntax
>> >> >    expression = term Infix..
>> >> >    term = (Prefix ...) Primitive (Suffix ...)  
>> >> > where "..." means repeat as many tiems as desired and "A B.." means
>> >> > repeat A separated by B (as in ABABABAB ...). The C syntax is almost
>> >> > already in that shape except for two points - one of them in the cast
>> >> > expression and the other the tertiary operator. (The tertiary can be
>> >> > forced into the right shape by looking at "QUERY expression COLON" as
>> >> > an Infix).
>> >> 
>> >> I can read the C grammar and, with some work, determine whether a given
>> >> expression is valid and how it's evaluated.
>> >> 
>> >> I can't do that with your description above, at least not without
>> >> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".
>> >
>> > Infix is any token in the set of tokens corresponding to binary 
>> > operators. Prefix is any token is the set of token corresponding
>> > to unary operators. Suffix is better limited to either "++" or "--"
>> > and all the other postfix treated as part of the primitive. Primitive
>> > (before that last change) means what the standard means by primary
>> > expression. It is possible to add embedded expressions (OPEN
>> > expression CLOSE) to the general syntax but the standard leaves thme
>> > as primitives.
>> >
>> > The reason why the names are all changed is that imposing a more
>> > general theory of parsing onto C parsing.  
>> >
>> >> Is that intended to be the entire grammar for expressions?  Would you
>> >> not have separate rules for additive, multiplicative, shift, and so
>> >> forth, expressions?
>> >  
>> > That's the whole thing.
>> >
>> >> And you haven't said anyting about constraints.  Would the meaning of
>> >> `x + y * z` be specified by the grammar (if so, what you've written above
>> >> doesn't do that), or by an English semantic description (if so, you
>> >> haven't mentioned it)?
>> >  
>> > The semantics are quite elaborate but we are only talking syntax
>> > here. 
>> 
>> C's syntax specifies how operands are associated with operators.  Your
>> proposed syntax does not.
>> 
>> >> Note that if the binding of `x + y * z` isn't defined by the grammar,
>> >> the rule saying that it's equivalent to `x + (y * z)` would not be a
>> >> constraint; it would be a semantic description.
>> >
>> > Actually it's a consequence of assigned token precedences and is buried
>> > in the semantics. 
>> 
>> Which you haven't described.
>
> OK each infix has two precednces - left and right. Each prefix has a
> left precedence. Suffixes has right precedences. There are two stacks -
> one for prefixes and one for data. Starting from the beginning - read 
> a token. (1) If it a prefixs push it on the stack (2) If it is a 
> primitive hold is a "the value". (3) If it is suffix or infix there 
> is an error. Note that tokens like MINUS or STAR can be both prefixes
> and infixes and here the prefix version is assumed. Repeat until a value
> is found. Read one more token. (1) If it is a suffix compare its right
> precedence to the top of the prefix stack and successively code applying
> the prefix to the value until the top of the stack has less precedence
> than the suffix and then apply the suffix to the value. (2) If it is an
> infix handle the stack the same way but instead of applying push the 
> infix onto the prefix stack and the value onto the value stack. (3) If it
> is any other token you have reached the end of the expression and you
> successively pop off prefixes until you get the final value. After (2)
> you repeat from the beginning. After (1) only one new token.
>
> I brushed over a couple of minor details but you get the idea.

You've haven't mentioned parentheses.

Do you really find this easier to understand than the existing syntax?

The reference to a "stack" suggests that this is targeted at compiler
developers, not at end users.

> Any compiler is going to have to do essentially this process even if
> the work is not so clearly marked off.   

The mapping from the grammar given in the standard to code that can
parse that grammar is fairly straightforward, and likely to be more
reliable that code written from a description like yours.

[...]

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

#67414

On 12/08/2015 01:24, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:

>> I want to define "expression" by the following syntax
>>     expression = term Infix..
>>     term = (Prefix ...) Primitive (Suffix ...)
>> where "..." means repeat as many tiems as desired and "A B.." means
>> repeat A separated by B (as in ABABABAB ...). The C syntax is almost
>> already in that shape except for two points - one of them in the cast
>> expression and the other the tertiary operator. (The tertiary can be
>> forced into the right shape by looking at "QUERY expression COLON" as
>> an Infix).
>
> I can read the C grammar and, with some work, determine whether a given
> expression is valid and how it's evaluated.
>
> I can't do that with your description above, at least not without
> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".
>
> Is that intended to be the entire grammar for expressions?  Would you
> not have separate rules for additive, multiplicative, shift, and so
> forth, expressions?

The above is essentially what I use when parsing expressions.

In the grammar (if I was to write one...) all binary operators have 
equal status. But operators also have a priority attribute, not 
expressed in the grammar, to give different preferences.

The way that the C grammar has a different production for each kind of 
operator seemed very odd when I first saw it, especially considering how 
many operator levels there are.

-- 
Bartc

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

#67111

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, August 10, 2015 at 8:05:47 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > The general strategy in C is to over-generate parses and then filter
>> > them semantically. Many of the semantic filters can also be done be
>> > done syntactically. IMO this is the correct strategy but it is not
>> > also followed. For example, "cast-expression" is an unfortunate way of
>> > introducing a semantic filter into syntax.
>> 
>> Can you expand on that point?  A cast-expression is just one of several
>> kinds of expressions defined in the syntax (primary-expression,
>> postfix-expression, unary-expression, cast-expression,
>> multiplicative-expression etc.), part of the scheme used to define
>> how expressions are parsed.  What is your objection?
>  
> Of course there is nothing wrong with cast-exprssion. It's just not
> elegant. Its effect is to prohibit certain sequences of unary
> operators (I think, ++,-- and sizeof followed by a cast). But this
> restriction on possible unary sequences can be handled by a (semantic)
> constraint more elegantly.

I'm still not quite sure what you're saying.  A cast-expression is just
one of a number of kinds of expressions, used to define what can also be
expressed in terms of operator precedence.  Would you prefer that C used
an operator precedence table instead of defining the precedence in the
grammar?  Or is the cast-expression a particular problem?

If you're thinking that a cast operator should be treated as a unary
operator, that would create an ambiguity, or at least would cause some
difficulties in parsing:
    sizeof (int) 42
That's 4 tokens that look like a valid expression, until you see the 42.
If the sizeof and cast operators has the same precedence, that would
require the parser  to backtrack and interpret the expression as
    sizeef ((int) 42)
Instead, it can simply report a syntax error because an integer constant
cannot appear immediately after a unary-expression.

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

#67065

In article <55C69FFA.7050309@verizon.net>,
James Kuyper  <jameskuyper@verizon.net> wrote:

>On 08/08/2015 07:06 PM, David Kleinecke wrote:
>...
>> I haven't been thinking of constraints as part of syntax. ...

>It would be more accurate to say that some constraints constrain the
>syntax.

It would make sense that a program must conform to both the grammar
and the constraints.

But in the case of implicit int in C90, the "constraint" in 6.5.2
explicitly allows something that is not allowed by the grammar.

-- Richard

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

#67071

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <55C69FFA.7050309@verizon.net>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
>
>>On 08/08/2015 07:06 PM, David Kleinecke wrote:
>>...
>>> I haven't been thinking of constraints as part of syntax. ...
>
>>It would be more accurate to say that some constraints constrain the
>>syntax.
>
> It would make sense that a program must conform to both the grammar
> and the constraints.
>
> But in the case of implicit int in C90, the "constraint" in 6.5.2
> explicitly allows something that is not allowed by the grammar.

Interesting, so it does.

For those who don't have a copy of C90, 6.5.2 covers type
specifiers.  A type specifier is one of void, char, short,
int, etc.  A declaration starts with a sequence of one or more
declaration specifiers, each of which is a storage-class specifier,
a type-specifier, or a type-qualifier.  The constraint in 6.5.2
restricts the list of type specifiers to one of a list of sets
(changed to "multisets" in C99 with the addition of long long,
though the wording wasn't updated until C11); for example, you
can't have "int int" or "short long" in a declaration.

One of the permitted sets of type specifiers is:

    -- int, signed, signed int, or no type specifiers

So this:

    x;

does not satisfy the grammar, but it is permitted by the constraint.
("auto x;" or "static x;" is permitted by the grammar.)

(Note that "x;" is ambiguous at block scope, where it could be an
expression statement; it's unambiguous at file scope where statements
are not permitted.  I think C90 has wording to resolve the ambiguity,
but I don't know exactly where it does so.)

This is yet another reason to be glad that the implicit int rule
is no longer with us.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web