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


Groups > comp.lang.c > #280466

Re: MCC Compiler

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: MCC Compiler
Date 2023-10-15 19:26 -0700
Organization A noiseless patient Spider
Message-ID <864jir8fpw.fsf@linuxsc.com> (permalink)
References <uf3n7a$3lfik$1@dont-email.me> <867co9j4jf.fsf@linuxsc.com> <uf51vi$3tg5h$1@dont-email.me> <86pm21h8es.fsf@linuxsc.com> <uf6a2e$809b$1@dont-email.me>

Show all headers | View raw


Bart <bc@freeuk.com> writes:

> On 29/09/2023 06:10, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>> to say about your experience working on compilers, especially
>> since those compilers are not written in C
>
> Is that really relevant?  Does a compiler for language L have to be
> written in L to be taken seriously?

What matters is whether you have something to say about
programming in C or about the C language.  Your compiler
isn't written in C so anything you have to say about the
compiler itself isn't relevant here, whether or not it
should be taken seriously.

In talking about how the compiler behaves, you don't say
anything that pertains to the C language.  I don't think
this notion is very hard to understand.  Talking about the
environment in which the compiler is built, even though it
might be interesting in other contexts, still has nothing
to do with the C language.

>> and aren't faithful to
>> the C language (and it isn't clear whether you don't know that or
>> if you just don't care).
>
> In which ways?

No one knows but you, and it's not even clear if you know.
Ironically, if you were to go through and make up a list of
differences between what your compiler accepts and what the
C standard requires, and present that list here, that WOULD
be topical, especially if there were reasons related to how
easy or hard some aspects of C are to compile.  For reasons
beyond understanding you leave out exactly the pieces of
information that would make it relevant in comp.lang.c.  I'm
at a loss to understand why you do that.

> My product compiles a C 'subset' but does not formally
> define what it is.

An informal definition is a lot better than no description
at all, and at least is something about the C language.
So figure out what the discrepancies are (and only you can
do that), and tell us about it.  That's why we're here!

> [speed of compiler]

There's nothing wrong with feeling pride in having written
a fast program (in a non-C language), but it's not a subject
of interest in this newsgroup.

> But it no longer supports my own extensions, like the many that gcc
> provides, and it no longer tries to improve on the language or fail
> programs on features I feel ought to be deprecated.

What would be relevant and possibly interesting is to say
what C language constructs you think should be considered
or left out.  Not what constructs IN OTHER LANGUAGES you
think are nice but what additions or changes to C you think
could add value.  Explain what, and leave it at that;  let
other people form their own opinions about how valuable
each change might be.

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


Thread

Re: MCC Compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-15 19:26 -0700
  Re: MCC Compiler Bart <bc@freeuk.com> - 2023-10-16 13:41 +0100

csiph-web