Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: What is C? Date: Sun, 30 Apr 2017 17:00:57 -0700 Organization: None to speak of Lines: 55 Message-ID: References: <830c4de1-bf1c-4526-8adb-b61f06a9f3c8@googlegroups.com> <5e8f29de-6f41-41ce-a4bf-4ed255c1eb9d@googlegroups.com> <63e54eb5-d907-4211-9d89-e17d0117792d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="40ab068b728f196ddeb1bab8be39060a"; logging-data="26572"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZLweiBac8H3zjvhshJ6NK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DpCJJ4Cg9UTx7VzgXdf8DZFqwAU= sha1:egIuSTbr9DMzj5tKJyBlQ7O+rNk= Xref: csiph.com comp.lang.c:108824 David Kleinecke writes: [...] > I'm taking a Chomskian point-of-view toward the language. I > don't usually run with the Chomskians but this is one place > I agree with them. > > I don't take the standard as a sacred text. Neither does anyone else. It's merely the document that defines the C language. > Looking at my > copy of the 1990 standard - in section 1 I read that the > standard specifies: > the representation of C programs > the syntax and constraints of the C language > the semantic rules for interpreting C programs > the representation of input data to be processed by C > programs > the representation of output data produced by C programs > the restrictions and limits imposed by a conforming > implementation of C Why are you ignoring the third point, "the semantic rules for interpreting C programs"? > As nearly as I can tell that says nothing about compilers - > meaning devices that make the semantic rules actually do > anything. It defines the phases of translation. I'm not sure whether it uses the word "compiler" or not. > So far as I know every serious compiler does not > produce actual machine code as output from the parser. Why does that matter? The existence of a parser as a component of the compiler is an irrelevant implementation detail. > I call whatever follows the parser output the back-end. > Just as I call the pre-processor the front end. Since the > standard does not discuss compiler structure this is a > legitimate thing to do. It's not legitimate when it leads you to define "the C language" in a way that ignores most of what the C language actually is. If you want to talk about the C syntax, or the C grammar, feel free to do so. Please don't pretend that that's all there is to the language. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"