because languages are specification, "books".
they are not interpreted nor compiled.
The most common implementations of the C language are compilers, yes, but "compiled" it's not a language property
As another denizen of this chain, I still don't see the confusion at all.
> because languages are specification, "books". they are not interpreted nor compiled
Languages are a specification, and an implementation working together in perfect harmony, with absolutely no undefined behaviour at all, yes, keep walking now.
At least... the good ones try to be, cough ignoring small half baked interpreters and compilers I've had the pleasure of working with cough and never touching again.
> The most common implementations of the C language are compilers, yes, but "compiled" it's not a language property
It absolutely is a large part of the C language and worth teaching, and I'd only split hairs in a programming language theory class, this is a book that presumably leaves the reader with a better grasp of C than before. And arguing against it is an exercise in personal experience I assume (you have C interpreter experience I wager?).
Most people are still taught C in terms of a compiler like gcc, or clang. Source code in, object code (for a specific language specification, target architecture, etc) out. Think operating systems, kernel modules, executables, dll's, and, etc.
I never touched a C interpreter (but I am curious at such a beast), but I know that C is fine to be referenced as "compiled".
so, is javascript an interpreted language?
what about jits?
...or babel, for what is worth.
if languages are "compiled" why does both C and C++ (and also java etc...) need a "memory model"? bare physical address and real threads should be enough, no?
> Languages are a specification, and an implementation working together in perfect harmony, with absolutely no undefined behaviour at all, yes, keep walking now.
never talked about "quality" or "comprehensiveness" of the specs.
Just that languages are specs, not implementations.
Yes, in the real world you will use gcc, and you will learn that you write some text stuff and it will transform to an executable for you.
Still, why don't you use the right terminology?
The problem is that, if a book slip on this -- so basic -- definition, how good can it be on the complex parts?
The root thing here is the author said "C is a compiled programming language". According to the objection, C is also, an, interpreted programming language so its not the correct classification. That's the complaint I read...
I just don't see this complaint as valid. From the discussion garnered here, C be both a compiled and interpreted language. This is a book about C in the context of the compiled variant, and has references to gcc and clang. The level of detail and nuance when using terminology here is used to match the context the terminology appears in. Excess verbiage for terminology isn't a panacea to confusion, in fact it can increase it. Can't "C is a compiled language" and "C is a interpreted language" both be true independently?
Don't get me wrong, I like reading perspectives like yours, because I just discovered a bunch about C interpreters.
But I feel like you are asking for a "spec" level document on modern C, when you are reading a more practical work on it.
It just so happens that the specification in this case makes very specific demands on the translation environment, closely describing compilation step by step from source files into a program image.
Your "interpreted C" is only C in the loose sense that one may describe other non-compliant but roughly similar implementations.
"Compiled" traditionally means "not interpreted", or rather "compiled to machine code".