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

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

What is C?

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

Contents

  What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 09:10 -0700
    Re: What is C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 18:26 +0200
      Re: What is C? Thiago Adams <thiago.adams@gmail.com> - 2017-04-29 12:31 -0700
        Re: What is C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 23:02 +0200
    Re: What is C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 18:07 +0100
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 10:44 -0700
        Re: What is C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 21:00 +0100
    Re: What is C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-29 16:45 -0700
    Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-29 22:54 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:48 -0700
        Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 12:02 -0700
          Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:24 -0700
            Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 17:00 -0700
              Re: What is C? supercat@casperkitty.com - 2017-04-30 18:00 -0700
              Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 09:41 -0700
                Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:25 -0500
                  Re: What is C? supercat@casperkitty.com - 2017-05-01 10:46 -0700
                    Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:04 -0500
                      Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 04:11 -0700
                        Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 00:48 -0500
                          Re: What is C? supercat@casperkitty.com - 2017-05-03 09:37 -0700
                            Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:45 -0500
                              Re: What is C? supercat@casperkitty.com - 2017-05-05 10:51 -0700
                          Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:32 -0700
                            Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 23:07 -0500
        Re: What is C? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-30 12:03 -0700
          Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:27 -0700
            Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 16:57 -0700
    Re: What is C? John Bode <jfbode1029@gmail.com> - 2017-05-01 10:13 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:26 -0700
        Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:50 -0500
        Re: What is C? John Bode <jfbode1029@gmail.com> - 2017-05-01 12:34 -0700
    Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 03:39 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:05 -0700

Page 1 of 2  [1] 2  Next page →

#108741 — What is C?

I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.

I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.

The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C. 

Today I would call the part of a bigger system (like gcc) 
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser. 

[toc] | [next] | [standalone]

#108743

On Sat, 29 Apr 2017 09:10:07 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:

> I have taken a position as to what "C" means that is not
> looked on favorably by several regulars on comp.lang.c.

Don't waste your time with C++ monkeys. They don't know how to write a correct
program in C and worse in C++ too. All what they know is to write some kind of
subset of C++ which looks like C but smell like sh!t.

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

#108749

On Saturday, April 29, 2017 at 1:29:50 PM UTC-3, GOTHIER Nathan wrote:
> On Sat, 29 Apr 2017 09:10:07 -0700 (PDT)
> David Kleinecke wrote:
> 
> > I have taken a position as to what "C" means that is not
> > looked on favorably by several regulars on comp.lang.c.
> 
> Don't waste your time with C++ monkeys. They don't know how to write a correct
> program in C and worse in C++ too. All what they know is to write some kind of
> subset of C++ which looks like C but smell like sh!t.

Can you show some samples of what is good C code for you?
Your code maybe?

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

#108753

On Sat, 29 Apr 2017 12:31:15 -0700 (PDT)
Thiago Adams <thiago.adams@gmail.com> wrote:
 
> Can you show some samples of what is good C code for you?
> Your code maybe?

Just get K&R but I have the sentiment you may prefer bananas... :o)

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

#108745

David Kleinecke <dkleinecke@gmail.com> writes:

> I have taken a position as to what "C" means that is not
> looked on favorably by several regulars on comp.lang.c.
> But I think I have never been clear exactly what I meant
> (I was probably unclear myself). I think now that I can
> say exactly what I think.
>
> I would say that the C language is the language defined by
> the phrase structure grammar.

That's small part of it, but a language where

  #include <stdio.h>
  int main(void) { printf("%d\n", 1+2); }

printed 42 would not be C (as other people interpret the name).

> I usually use the grammar
> from C89 but the later standards, so far a I know, haven't
> changed it much. The grammar in K&R 78 is too incomplete
> to use.

C can't be described by a context-free grammar like those in the
standard and the two editions of K&R.  The two big problems are the
pre-processor and the syntactic role played by typedef names.

> The C so defined is incomplete as a programming tool. These
> days there is both pre and post processing. But - as I see
> the situation - neither are intrinsic parts of C.

The pre-processor is an intrinsic part of (what the world calls) C.  You
can use the term in some other way, but I'd advise against that.  Usenet
is nothing if not the natural home for people who define things how they
like.

<snip>
-- 
Ben.

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

#108746

On Saturday, April 29, 2017 at 10:07:19 AM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > I have taken a position as to what "C" means that is not
> > looked on favorably by several regulars on comp.lang.c.
> > But I think I have never been clear exactly what I meant
> > (I was probably unclear myself). I think now that I can
> > say exactly what I think.
> >
> > I would say that the C language is the language defined by
> > the phrase structure grammar.
> 
> That's small part of it, but a language where
> 
>   #include <stdio.h>
>   int main(void) { printf("%d\n", 1+2); }
> 
> printed 42 would not be C (as other people interpret the name).
> 
> > I usually use the grammar
> > from C89 but the later standards, so far a I know, haven't
> > changed it much. The grammar in K&R 78 is too incomplete
> > to use.
> 
> C can't be described by a context-free grammar like those in the
> standard and the two editions of K&R.  The two big problems are the
> pre-processor and the syntactic role played by typedef names.
> 
> > The C so defined is incomplete as a programming tool. These
> > days there is both pre and post processing. But - as I see
> > the situation - neither are intrinsic parts of C.
> 
> The pre-processor is an intrinsic part of (what the world calls) C.  You
> can use the term in some other way, but I'd advise against that.  Usenet
> is nothing if not the natural home for people who define things how they
> like.
 
It is possible to write a C program that does nothing in the
preprocessor except ignore end-of-lines. But in some sense
every C program requires a tokenizer. That does not mean that
the tokenizer (or the preprocessor) is part of the phrase
structure C because the same phrase structure could proceed
just as well with a different pre-processor (and likewise the
post-processing). It seems to me that the status of the
pre-processor is exactly the same as the status of the standard
library.

That is, from an architectural point-of-view, a C compiler (in
the broad sense) has three parts:
    a preprocessor translating something external into tokens
    the parser
    a postprocessor that ultimately produces machine code
There is a string of tokens passed from the preprocessor to the
parser and a string of instructions in an intermediate code
passed from the parser to the back end.

I have (as yet not completely developed) theories about both of
these strings.

I believe it is necessary to allow the parser to digest the entire
token string before it makes any output so while the pre-processor
C now normally uses can be piped into the parser it is not possible
to meaingfully pipe the parser output.

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

#108752

David Kleinecke <dkleinecke@gmail.com> writes:

> On Saturday, April 29, 2017 at 10:07:19 AM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> 
>> > I have taken a position as to what "C" means that is not
>> > looked on favorably by several regulars on comp.lang.c.
>> > But I think I have never been clear exactly what I meant
>> > (I was probably unclear myself). I think now that I can
>> > say exactly what I think.
>> >
>> > I would say that the C language is the language defined by
>> > the phrase structure grammar.
>> 
>> That's small part of it, but a language where
>> 
>>   #include <stdio.h>
>>   int main(void) { printf("%d\n", 1+2); }
>> 
>> printed 42 would not be C (as other people interpret the name).
>> 
>> > I usually use the grammar
>> > from C89 but the later standards, so far a I know, haven't
>> > changed it much. The grammar in K&R 78 is too incomplete
>> > to use.
>> 
>> C can't be described by a context-free grammar like those in the
>> standard and the two editions of K&R.  The two big problems are the
>> pre-processor and the syntactic role played by typedef names.
>> 
>> > The C so defined is incomplete as a programming tool. These
>> > days there is both pre and post processing. But - as I see
>> > the situation - neither are intrinsic parts of C.
>> 
>> The pre-processor is an intrinsic part of (what the world calls) C.  You
>> can use the term in some other way, but I'd advise against that.  Usenet
>> is nothing if not the natural home for people who define things how they
>> like.
>  
> It is possible to write a C program that does nothing in the
> preprocessor except ignore end-of-lines.
<snip>

Thanks.  I am beginning to understand the purpose of your posts.
-- 
Ben.

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

#108757

On Saturday, April 29, 2017 at 12:10:27 PM UTC-4, David Kleinecke wrote:
> I would say that the C language is the language defined by
> the phrase structure grammar.

In my view there are two Cs.  The first is the language appearance and
grammar mechanics describing logical operation.  This is comprised of
things human beings would readily use to translate thought into an
explicit form the compiler can reliably interpret.  The second is the
inner compilation mechanism which takes that grammar and structure and
produces replicable output on any system.

I personally tend to place greater significance on the language
appearance and the mechanics describing logical operation, and less
significance on the actual output.  Why this seemingly huge discrepancy?
I do this because the variations between "reasonable" C compilers are
typically very small, meaning while they can produce code that works
perfectly on one system, and flatly fails on another, they are typically
overcome by changing only one or two small things.  And, it's easy to
create tests and compare one compiler to another so as to easily track
down what is different in each.

As a result, far greater ease is found in identifying differences be-
tween C compilers, while the overall complexity of the grammar and
language mechanics outweighing the generated code by a large margin.

Note:  This conclusion assumes, of course, reasonable C compilers ...
       meaning C compilers that will generally produce correct code
       when not dealing with fringe cases.

-----
I believe C is a philosophical approach to translating human thought
into machine expression more than anything else.  There is no other
language quite like it.  It's close to metal, not overly verbose for
what it does, and requires only a handful of extensions to make it a
truly desirable language for its class of developers.

Thank you,
Rick C. Hodgin

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

#108758

David Kleinecke <dkleinecke@gmail.com> writes:
> I have taken a position as to what "C" means that is not
> looked on favorably by several regulars on comp.lang.c.
> But I think I have never been clear exactly what I meant
> (I was probably unclear myself). I think now that I can
> say exactly what I think.
>
> I would say that the C language is the language defined by
> the phrase structure grammar. I usually use the grammar
> from C89 but the later standards, so far a I know, haven't
> changed it much. The grammar in K&R 78 is too incomplete
> to use.
>
> The C so defined is incomplete as a programming tool. These
> days there is both pre and post processing. But - as I see
> the situation - neither are intrinsic parts of C. 

I'd say that the syntax is just one part of the language, and not the
the most important part.  In a sense it distinguishes between what is
and is not a C program, but it says nothing about what any C code
*means*.

[...]

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

#108791

On Saturday, April 29, 2017 at 10:55:06 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > I have taken a position as to what "C" means that is not
> > looked on favorably by several regulars on comp.lang.c.
> > But I think I have never been clear exactly what I meant
> > (I was probably unclear myself). I think now that I can
> > say exactly what I think.
> >
> > I would say that the C language is the language defined by
> > the phrase structure grammar. I usually use the grammar
> > from C89 but the later standards, so far a I know, haven't
> > changed it much. The grammar in K&R 78 is too incomplete
> > to use.
> >
> > The C so defined is incomplete as a programming tool. These
> > days there is both pre and post processing. But - as I see
> > the situation - neither are intrinsic parts of C. 
> 
> I'd say that the syntax is just one part of the language, and not the
> the most important part.  In a sense it distinguishes between what is
> and is not a C program, but it says nothing about what any C code
> *means*.
> 
> [...]
 
Exactly so. The C language does not say anything about what it
means. The meaning is mapped into the language by the front and
back ends.

For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.

That message can take different shapes but I think a stack
"accumulator" is the easiest to follow so "a=b+c" might be
passed to the back end as three instructions
    @ = b
    @ + c
    a = @
(@ being the stack of values).  

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

#108792

David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, April 29, 2017 at 10:55:06 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > I have taken a position as to what "C" means that is not
>> > looked on favorably by several regulars on comp.lang.c.
>> > But I think I have never been clear exactly what I meant
>> > (I was probably unclear myself). I think now that I can
>> > say exactly what I think.
>> >
>> > I would say that the C language is the language defined by
>> > the phrase structure grammar. I usually use the grammar
>> > from C89 but the later standards, so far a I know, haven't
>> > changed it much. The grammar in K&R 78 is too incomplete
>> > to use.
>> >
>> > The C so defined is incomplete as a programming tool. These
>> > days there is both pre and post processing. But - as I see
>> > the situation - neither are intrinsic parts of C. 
>> 
>> I'd say that the syntax is just one part of the language, and not the
>> the most important part.  In a sense it distinguishes between what is
>> and is not a C program, but it says nothing about what any C code
>> *means*.
>> 
>> [...]
>  
> Exactly so. The C language does not say anything about what it
> means. The meaning is mapped into the language by the front and
> back ends.

You seem to be using the word "language" in a very odd sense.

The C language certainly does define the meaning of C code (leaving it
undefined in some cases).  That definition is mostly in section 6 of the
ISO C standard.

The grammar defines the syntax of the language.  That syntax is no more
and no less part of "the C language" than the semantics.

It might be reasonable to exclude section 7, which specifies the
library, from the phrase "the C language", but surely everthing in
section 6 is part of "the C language".

> For example, the C language tells us nothing about what '+'
> means. It sends to the back end a message that two values
> (a value is assumed to be a type-and-address pair) are
> operated on by an operator named '+' to produce another
> value.

No, the C language tells us that "The result of the binary +
operator is the sum of the operands" (C11 6.5.6p5).

What is this "back end" you're talking about?  There is no mention
of it in the standard that defines the language.

What you're describing is the C syntax, not the C language.

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

#108817

On Sunday, April 30, 2017 at 12:02:24 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Saturday, April 29, 2017 at 10:55:06 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> > I have taken a position as to what "C" means that is not
> >> > looked on favorably by several regulars on comp.lang.c.
> >> > But I think I have never been clear exactly what I meant
> >> > (I was probably unclear myself). I think now that I can
> >> > say exactly what I think.
> >> >
> >> > I would say that the C language is the language defined by
> >> > the phrase structure grammar. I usually use the grammar
> >> > from C89 but the later standards, so far a I know, haven't
> >> > changed it much. The grammar in K&R 78 is too incomplete
> >> > to use.
> >> >
> >> > The C so defined is incomplete as a programming tool. These
> >> > days there is both pre and post processing. But - as I see
> >> > the situation - neither are intrinsic parts of C. 
> >> 
> >> I'd say that the syntax is just one part of the language, and not the
> >> the most important part.  In a sense it distinguishes between what is
> >> and is not a C program, but it says nothing about what any C code
> >> *means*.
> >> 
> >> [...]
> >  
> > Exactly so. The C language does not say anything about what it
> > means. The meaning is mapped into the language by the front and
> > back ends.
> 
> You seem to be using the word "language" in a very odd sense.
> 
> The C language certainly does define the meaning of C code (leaving it
> undefined in some cases).  That definition is mostly in section 6 of the
> ISO C standard.
> 
> The grammar defines the syntax of the language.  That syntax is no more
> and no less part of "the C language" than the semantics.
> 
> It might be reasonable to exclude section 7, which specifies the
> library, from the phrase "the C language", but surely everthing in
> section 6 is part of "the C language".
> 
> > For example, the C language tells us nothing about what '+'
> > means. It sends to the back end a message that two values
> > (a value is assumed to be a type-and-address pair) are
> > operated on by an operator named '+' to produce another
> > value.
> 
> No, the C language tells us that "The result of the binary +
> operator is the sum of the operands" (C11 6.5.6p5).
> 
> What is this "back end" you're talking about?  There is no mention
> of it in the standard that defines the language.
> 
> What you're describing is the C syntax, not the C language.

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. 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
As nearly as I can tell that says nothing about compilers -
meaning devices that make the semantic rules actually do
anything. So far as I know every serious compiler does not
produce actual machine code as output from the parser.
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. 

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

#108824

David Kleinecke <dkleinecke@gmail.com> 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  <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]

#108828

On Sunday, April 30, 2017 at 7:01:04 PM UTC-5, Keith Thompson wrote:
> Neither does anyone else.  It's merely the document that defines
> the C language.

From what I can tell, it defines three things:

1. Things that are Conforming C implementations.

2. Things that are Strictly Conforming C programs.

3. Things that are Conforming C programs but are not Strictly Conforming.

In a language like Java, an expression like (65535 * 65537) has a meaning
which is independent of the implementation (if I figured it right, -1).
By contrast, the meaning of that expression in C would depend upon the
platform implementing it.  One could say that the mapping of Strictly
Conforming source texts to outputs is "the C language", but such a language
is rather anemic and unsuitable for most purposes to which its offshoots
are put.

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

#108892

On Sunday, April 30, 2017 at 5:01:04 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> 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.

Think about modules. The front and back ends on either side
of the parser are interchangeable with other versions while
the parser stays fixed. 

But the standard includes the "standard library" which is not
to be considered part of the C language in any sense of language.
The standard itself goes almost all the way to acknowledging
this by introducing the concept of freestanding implementation.

Backend questions like optimization are ignored by the standard.
The pre-processor has some claim to be part of the language but
it could be replaced by another tokenizer without any change to
syntax or semantics. 

The syntax could be changed too - but IMO that would most often
change the language to something other than C.

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

#108902

On Mon, 1 May 2017 09:41:23 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Sunday, April 30, 2017 at 5:01:04 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> 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.
>
>Think about modules. The front and back ends on either side
>of the parser are interchangeable with other versions while
>the parser stays fixed. 
>
>But the standard includes the "standard library" which is not
>to be considered part of the C language in any sense of language.
>The standard itself goes almost all the way to acknowledging
>this by introducing the concept of freestanding implementation.


The standard also gives freestanding implementations the option to
ignore the complex types.  Does that make the complex types not part
of the language?  The standard does not specify that a free standing
implementation may have *no* library, but only requires a much smaller
one than is necessary for a hosted implementation.  Or is then the
"non-language" part of the library only the stuff not required in a
freestanding implementation.

And if none of the library is part of the language, how would you
classify the (require) offsetof macro?

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

#108906

On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
> And if none of the library is part of the language, how would you
> classify the (require) offsetof macro?

What is referred to as the "standard library" generally has two parts: a set
of header files, and a set of linkable functions.  In general, the Standard
allows freestanding implementations to omit the parts of the Standard Library
that would require the use of linked-in functions, though ironically it
requires implementations to include numeric types that would often require
linking in helper functions.  Freestanding implementation are sometimes used
to generate code for functions that need to be 100% stand-alone and use
nothing beyond the stack and any arguments that are passed to them.  If it
won't be possible for a function to call *any* outside functions except those
whose address was passed via parameters, it would be better to have the
compiler refuse any code that would require use of an outside helper
function, than to have it generate code that would fail at link time (or
worse, at run time).

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

#108909

On Mon, 1 May 2017 10:46:37 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
>> And if none of the library is part of the language, how would you
>> classify the (require) offsetof macro?
>
>What is referred to as the "standard library" generally has two parts: a set
>of header files, and a set of linkable functions.


While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker.  Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.

And who's to say that on some platform offsetof doesn't need to call a
helper function?


>In general, the Standard
>allows freestanding implementations to omit the parts of the Standard Library
>that would require the use of linked-in functions, though ironically it
>requires implementations to include numeric types that would often require
>linking in helper functions. Freestanding implementation are sometimes used
>to generate code for functions that need to be 100% stand-alone and use
>nothing beyond the stack and any arguments that are passed to them.  If it
>won't be possible for a function to call *any* outside functions except those
>whose address was passed via parameters, it would be better to have the
>compiler refuse any code that would require use of an outside helper
>function, than to have it generate code that would fail at link time (or
>worse, at run time).


That's a requirement beyond any imposed by the standard, and the
resulting language would not really be C.

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

#109019

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Mon, 1 May 2017 10:46:37 -0700 (PDT), supercat@casperkitty.com
> wrote:
>
>> On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
>>> And if none of the library is part of the language, how would you
>>> classify the (require) offsetof macro?
>>
>> What is referred to as the "standard library" generally has two
>> parts:  a set of header files, and a set of linkable functions.
>
> While practically true, the standard really doesn't say much about
> what, if any, functions defined in the standard headers will actually
> result in some external code being brought in by the linker.  Nor does
> it say any such a thing about how the core language itself operates -
> many small processors will call runt time library code of some sort
> for the more complex arithmetic operations.
>
> And who's to say that on some platform offsetof doesn't need to call a
> helper function?

The result of offsetof() is an integer constant expression, and
so can be part of the value of an enumeration constant, the bound
of a static array, or a 'case' expression.  That seems to rule
out the involvement of library functions (even internal ones) in
the usual sense of the term.

(P.S.  I love the idea that small processors have runt time
libraries.)

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

#109087

On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Mon, 1 May 2017 10:46:37 -0700 (PDT), supercat@casperkitty.com
>> wrote:
>>
>>> On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
>>>> And if none of the library is part of the language, how would you
>>>> classify the (require) offsetof macro?
>>>
>>> What is referred to as the "standard library" generally has two
>>> parts:  a set of header files, and a set of linkable functions.
>>
>> While practically true, the standard really doesn't say much about
>> what, if any, functions defined in the standard headers will actually
>> result in some external code being brought in by the linker.  Nor does
>> it say any such a thing about how the core language itself operates -
>> many small processors will call runt time library code of some sort
>> for the more complex arithmetic operations.
>>
>> And who's to say that on some platform offsetof doesn't need to call a
>> helper function?
>
>The result of offsetof() is an integer constant expression, and
>so can be part of the value of an enumeration constant, the bound
>of a static array, or a 'case' expression.  That seems to rule
>out the involvement of library functions (even internal ones) in
>the usual sense of the term.


I believe you're right.  OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.


>(P.S.  I love the idea that small processors have runt time
>libraries.)


I wish I could take credit, just a typo.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web