Re: another C-like language? was Compilers :)

On 05/01/2023 15:27, marb...@yahoo.co.uk wrote:
> On Tuesday, 3 January 2023 at 17:45:17 UTC, Steve Limb wrote:
>> I’m not sure there would be that much demand for a cut down C.
>
> I recently read (well, skimmed)
> http://www.mjbauer.biz/C-less%20Reference%20Manual.pdf
> "A concise subset of the C programming language".
> Though I'm a bit baffled by some of Bauer's choices. Why is
> `char *foo="foo", *bar="bar"; puts(foo); puts(bar);`
> allowed but not
> `char *foo="foo"; puts(foo); char *bar="bar"; puts(bar);`
> ? Admittedly, the latter is only allowed in relatively recent C, but from my
> (very limited) experience writing compilers, the latter is no harder to
> compile.


By "relatively recent C", you mean C99 ? Mixing statements and
declarations was standardised in C nearly 25 years ago, and was probably
implemented at least a decade before that in some compilers. (Some C
compilers incorporated features from C++ that later became standardised
in C99.)


> I idly thought about adding stuff to C-less and calling it C-more-or-less,
> Cmol, for short.


There have been many "sort-of-C" languages made, as well as
"sort-of-C++". (Embedded C++ was one attempt at making a simpler subset
of C++ for use in embedded systems - despite significant backing, it has
failed completely.)


One subset of C that was useful is C--. This was aimed at being a code
generation target for higher level languages, to improve portability and
save the high level compiler writers from learning the details of
assembly language on different targets. I think these days it is more
common to target LLVM or a common virtual machine (such as JVM) for such
purposes.




The "C-less" language referenced in the link above seems to be targeting
"a first course in embedded programming". As an embedded programmer by
profession, I would not want to hire a new developer that had learned
"C-less". They would /think/ that they could program in C, but be
mislead in several areas and have learned a number of bad habits. (I
don't want to go through them all, but I agree with you that the style
of "all your declarations at the start of the function" is long
outdated, and often - but not universally - considered a bad idea.)


I also find it strange that this is supposedly a description of parts of
the C language, but regularly uses different terms from the C standards
and other C documentation for no visible benefit. This could only serve
to confuse the student.




> I'm up for reading the source of any relatively simple compiler for, and
> written in, anything C-like. I've tried making sense of the GNU C compiler a
> few times. My brain may recover one day!


gcc is the result of thousands of man-hours, spread over about 5 decades
and thousands of contributors. No, it is not an easy read! I think
"LCC" is probably the best choice of a simple C compiler to read and
understand - this was part of the motivation for writing it. "Tiny C
Compiler" is another option.




> [If you're doing a one-pass compiler, it's easier if all the declarations are at the
> beginning so you can generate the code to set up the stack frame and do initializations.
> I agree that on modern computers it's not a big deal, but remember that early C compilers
> ran in 24K bytes and I don't mean meagabytes. -John]


If you are writing a compiler for use by people writing code, then being
able to mix declarations and statements is hugely important - and since
generally people /use/ compilers more than they write them, the
trade-off should be on the side of the effort for the users, rather than
the compiler writers.


But if you are writing it for fun, or to learn about compiler writing,
then of course a simpler language is easier. And if your aim is for an
intermediary language generated by a higher level compiler, then a
simple subset is also convenient.

Return to the comp.compilers page.
Search the comp.compilers archives again.