Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #280466
| 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> |
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 | Next — Next in thread | Find similar | Unroll 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