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

Groups > comp.lang.c > #120555

Re: Lexical Elements

Show all headers | View raw

David Kleinecke <dkleinecke@gmail.com> writes:

> On Thursday, September 28, 2017 at 6:40:08 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Thursday, September 28, 2017 at 12:38:02 PM UTC-7, Keith Thompson wrote:
>> >> 
>> >> A compiler typically treats syntax and semantics separately.  Syntactic
>> >> analysis, or parsing, is often semi-automated, with the parser generated
>> >> programatically from a forma grammar -- or it might be written manually.
>> >> If parsing fails, that's a syntax error.  Other errors, like trying to
>> >> apply a shift operator to a pointer value, have to be detected during
>> >> semantic analysis.  As far as typical compiler internals are concerned,
>> >> they're fundamentally different kinds of errors.  Tweaking the grammar
>> >> to treat some syntax errors as semantic errors can enable better
>> >> diagnostics in some csaes.
>> >  
>> > My compilers also treat syntax and semantics separately. The
>> > question is whether the constraints are part of syntax or part
>> > of semantics. 
>> 
>> Semantics, I'd say.
>> 
>> > You imply that some are and some aren't.
>> 
>> Did I?
>> 
>> >                                          Quite possible
>> > although I have no examples. I have concluded that what
>> > I called the spirit of C expects them with the syntax but
>> > I had them coded with the semantics. I have only begun
>> > moving the constraints and haven't yet found any that
>> > don't fit rather easily into the syntax. 
>> 
>> I suspect I really don't undrestand what you're saying.
>> 
>> Here's an example.  C11 6.8.4.2p1 specifies the following constraint:
>> 
>>     The controlling expression of a switch statement shall have integer
>>     type.
>> 
>> Unless you extend the meaning of "syntax" beyond (my) recognition, you
>> won't be able to enforce that constraint using only syntax information.
>> 
>> Roughly, a syntax error is a failure to parse the source code in
>> accordance with a grammar that can be defined, for example, in BNF
>> (Backus-Naur Form).  (C's treatment of typedefs punches a small hole in
>> this model.)  Any errors that are not syntax errors are what I think of
>> as semantic errors.  In C, this is more or less expressed as syntax
>> rules vs. constraints.
>
> I understand syntax, perhaps, like a linguist would. In
> all the linguistic work I know what fills a slot (a slot
> like the identifier slot in a switch statement) can be
> sub-categorized to a subset of all identifiers. In this
> case the identifier must have the attribute "integer".
> The token (already identified as an identifier) is further
> sub-categorized by being declared, for example, an "int".

Perhaps you could show us the grammar you use in which the given
constraint is a syntax error?

Such a grammar does exist as you, as a linguist, will know.  It's not
the grammar in the C standard, and it may well be so much more complex
that it can't be parsed efficiently, but know what it is before
embarking on this part of the project will help you immensely.

Keith is correct in that most constraints are not syntax errors taking
the language syntax to be the described by the grammar in the standard.
You are correct in that any set of static properties of a text (and the
constraints in the C standard are all checkable by inspecting the text
of one translation unit alone) can be turned into a grammar such that
violating one or more of them becomes a matter solely of syntax.

However, there are sounds reasons why that approach is not taken in most
programming languages.

What seems more likely is that are plannign to parse the syntax as in
the standard C grammar and maintain extra information as you go that can
be used to diagnose constraint violations.  That's how every C compiler
I have ever seen does it.

> The source of my concern about what a token actually is
> comes from this accumulation of additional attributes -
> which would include constant and volatile as well as
> static/extern.

This sounds like the usual approach.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-27 19:03 -0700
  Re: Lexical Elements "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-09-28 05:33 +0200
    Re: Lexical Elements James Kuyper <jameskuyper@verizon.net> - 2017-09-28 00:19 -0400
      Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-27 22:09 -0700
        Re: Lexical Elements Keith Thompson <kst-u@mib.org> - 2017-09-28 08:31 -0700
          Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 11:53 -0700
            Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 12:16 -0700
              Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 15:51 -0700
                Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 16:42 -0700
            Re: Lexical Elements Keith Thompson <kst-u@mib.org> - 2017-09-28 12:37 -0700
              Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 16:16 -0700
                Re: Lexical Elements Keith Thompson <kst-u@mib.org> - 2017-09-28 18:39 -0700
                Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 19:47 -0700
                Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 20:29 -0700
                Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 22:36 -0700
                Re: Lexical Elements Keith Thompson <kst-u@mib.org> - 2017-09-29 08:47 -0700
                Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 11:23 -0700
                Re: Lexical Elements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 18:27 +0100
        Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 09:13 -0700
    Re: Lexical Elements Richard Damon <Richard@Damon-Family.org> - 2017-09-28 08:15 -0400
  Re: Lexical Elements jameskuyper@verizon.net - 2017-09-27 21:03 -0700
    Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-27 22:16 -0700
      Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 09:45 -0700
        Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 11:58 -0700
          Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 12:29 -0700
            Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 15:52 -0700
              Re: Lexical Elements Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-09-28 17:40 -0600
              Re: Lexical Elements jameskuyper@verizon.net - 2017-09-28 16:54 -0700
          Re: Lexical Elements Keith Thompson <kst-u@mib.org> - 2017-09-28 12:40 -0700
            Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 16:12 -0700
          Re: Lexical Elements bartc <bc@freeuk.com> - 2017-09-28 21:04 +0100
            Re: Lexical Elements bartc <bc@freeuk.com> - 2017-09-28 22:12 +0100
            Re: Lexical Elements David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 16:15 -0700
              Re: Lexical Elements bartc <bc@freeuk.com> - 2017-09-29 01:19 +0100

csiph-web