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


Groups > comp.lang.c > #120546

Re: Lexical Elements

Path csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: Lexical Elements
Date Fri, 29 Sep 2017 08:47:29 -0700
Organization None to speak of
Lines 66
Message-ID <lna81dv75a.fsf@kst-u.example.com> (permalink)
References <cc7eadf6-6c89-4139-9050-3606d3c0ab01@googlegroups.com> <m2o9pv33am.fsf@despina.home> <oqht8d$ke3$1@dont-email.me> <e1753783-684f-45a1-8600-e0230fa9ba81@googlegroups.com> <lnmv5eyh4k.fsf@kst-u.example.com> <d7b80520-7c0a-461f-99db-1b58dac1ee15@googlegroups.com> <lnk20iwr59.fsf@kst-u.example.com> <d1352da5-c14d-445d-953a-b623686873f2@googlegroups.com> <lning2uvtc.fsf@kst-u.example.com> <2d14fe25-9390-4711-b8e2-1cdefc3d56bf@googlegroups.com>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Injection-Info reader02.eternal-september.org; posting-host="61a8d29e3e3ce5c1ce3f75578cd619a7"; logging-data="10348"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hBKWoKB2X9HFVRZkUavBe"
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock sha1:afuFlBTuJGTanm4xO8BZubp9CgY= sha1:uHw0yKrvyIDraI3HPKmHA4fsFKw=
Xref csiph.com comp.lang.c:120546

Show key headers only | View raw


David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, September 28, 2017 at 6:40:08 PM UTC-7, Keith Thompson wrote:
[...]
>> 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".

I'm not a linguist, but I suspect that you're looking at syntax in a way
that's not useful for analyzing C.

There is no "identifier slot" in a switch statement.  What follows the
"switch" keyword is an expression.  That expression can be arbitrarily
complex, but it must be of some integer type.  The attribute "integer",
if you have such a thing, would need to apply to (your internal
representation of) that expression, not to some identifier.

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

In a typical compiler design, input is split into tokens by the "lexer".
Each token is derived from a sequence of characters in the source.  One
kind of token is an identifier.  At the token level, an identifier has
no type and does not refer to any declaration; those concepts occur
later in processing.  All you need to know about it at that point is
that it's an identifier and how it's spelled.

The stream of tokens is consumed by the parser, which does all the
syntactic analysis.  The parser might build some data structure that
reflects the syntax (declarations, statements, function definitions,
etc.).  That structure may or may not use the token stuctures built by
the lexer, but it will at least need to annotate them with extra
information.

But as for const/volatile/static/extern, those are attributes that
should apply to a declaration, not to an identifier.  The parser would
figure out, for example, which declaration a given occurrence of an
identifier refers to.

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

Back to comp.lang.c | Previous | NextPrevious 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