"C: Everyone's favourite programming language isn't a programming language"

Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

Richard Harnden <richard.nospam@gmail.com> writes:
>"C: Everyone's favourite programming language isn't a programming language"
>
>Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

The article doesn't make a whole lot of sense - it's basically just
bitching because swift and rust can't do everything that C can.

Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
> Richard Harnden <richard.nospam@gmail.com> writes:
>> "C: Everyone's favourite programming language isn't a programming language"
>>
>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>
> The article doesn't make a whole lot of sense - it's basically just
> bitching because swift and rust can't do everything that C can.

And you're putting it lightly.
Of course, first thing, without even reading it, is questioning the
relevance of such articles written by heavy proponents of "alternative"
languages. How much more biased can one be?

Digging a bit deeper, there is nothing much to even take from this short
article. It's pretty shallow.

- C is difficult to parse? C declarations are, for instance, not exactly
easy, but it's only very moderately difficult. You can have fun with
this to get an idea: https://cdecl.org/ . I has never made it a problem
to write a C compiler. There are more of them out there than for any
other language, I think. OTOH, there is, AFAIK, only one implementation
of Rust. Which to me is in itself a problem. I'm curious to see if it
ever even gets to the point of having other competing implementations.

- Incompatible variants? What exactly is this referring to? If you stick
to the standard, the amount of back-compatibility is one of the best
among all existing languages. That's actually one of its strong points.

- Integer arithmetics: that's admittedly not the best in C, but in most
cases for performance reasons.

The rest is indeed just a rant about other languages having to interface
with C for a lot of applications. That would be a bit like ranting that
english has become the de facto international language, while you'd
prefer it to be spanish, because uh, it's so much more elegant, or
something.

And about interfacing, I'm then also curious as to how well one could
interface with Rust and Swift on a large scale.

scott@slp53.sl.home (Scott Lurndal) writes:
> Richard Harnden <richard.nospam@gmail.com> writes:
>>"C: Everyone's favourite programming language isn't a programming language"
>>
>>Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>
> The article doesn't make a whole lot of sense - it's basically just
> bitching because swift and rust can't do everything that C can.

It makes some interesting and valid points -- none of which have
anything at all to do with the claim in the title.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Guillaume <message@bottle.org> writes:
> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>> Richard Harnden <richard.nospam@gmail.com> writes:
>>> "C: Everyone's favourite programming language isn't a programming language"
>>>
>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>> The article doesn't make a whole lot of sense - it's basically just
>> bitching because swift and rust can't do everything that C can.
>
> And you're putting it lightly.
> Of course, first thing, without even reading it, is questioning the
> relevance of such articles written by heavy proponents of
> "alternative" languages. How much more biased can one be?
>
> Digging a bit deeper, there is nothing much to even take from this
> short article. It's pretty shallow.
>
> - C is difficult to parse? C declarations are, for instance, not
> exactly easy, but it's only very moderately difficult. You can have
> fun with this to get an idea: https://cdecl.org/ . I has never made
> it a problem to write a C compiler. There are more of them out there
> than for any other language, I think. OTOH, there is, AFAIK, only one
> implementation of Rust. Which to me is in itself a problem. I'm
> curious to see if it ever even gets to the point of having other
> competing implementations.

It's probably referring to the typedef issue.

In the absence of typedefs, type names consist of keywords and
punctuation. A typedef (a feature that was added to the language
after the syntax had been established) creates a type name that's an
identifier. It's impossible to parse something that uses a typedef name
without knowing that it's a typedef name. In effect a typedef adds a
context-sensitive keyword to the grammar. The parser needs to query the
symbol table.

But it's a solved problem and not that big a deal.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Richard Harnden <richard.nospam@gmail.com> writes:

> "C: Everyone's favourite programming language isn't a programming language"
>
> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

Is this a click bait article? The answer might surprise you!

--
Ben.

On 2022-03-24, Guillaume <message@bottle.org> wrote:
> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>> Richard Harnden <richard.nospam@gmail.com> writes:
>>> "C: Everyone's favourite programming language isn't a programming language"
>>>
>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>
>> The article doesn't make a whole lot of sense - it's basically just
>> bitching because swift and rust can't do everything that C can.
>
> And you're putting it lightly.
> Of course, first thing, without even reading it, is questioning the
> relevance of such articles written by heavy proponents of "alternative"
> languages. How much more biased can one be?

One can be accurate in promoting. This article shows a lack of
understanding of the difference between a binary interface, and a
programming language.

There is a relationship in that the C language is oriented toward
working with "value types" which describe objects having a concrete
layout in memory.

Manhy platforms have an ABI that is part of a locus of documents
and software that includes a toolchain with a C compiler.

Specific binary interfaces such as libraries are often accompanied
by C headers. Those headers do not give the full semantics; it is a
fallacy to believe that those binary interfaces are "C language"
interfaces just because there are C headers.

The Gnome project, for instance uses an XML notation to describe
binary interfaces, and that XML notation gives semantic details like
ownership of memory passed by pointer and whatnot.

You can process that XML to produce FFI bindings without touching a C
header file.

Now, software components that are actually written in C will have "easy"
binary interfaces, by and large, in the sense that there won't be a lot
of difficult to handle compiler-generated boiler plate in the data
structuring (as might be in the case of C++ objects, say).

These Rust and Swift and whatnot pushing scallywags should count
themselves fortunate and express gratitude when they have an easy target
to hit due to some binary interface being designed and implemented in C.

On 3/24/2022 1:36 PM, Keith Thompson wrote:
> Guillaume <message@bottle.org> writes:
>> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>> "C: Everyone's favourite programming language isn't a programming language"
>>>>
>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>> The article doesn't make a whole lot of sense - it's basically just
>>> bitching because swift and rust can't do everything that C can.
>>
>> And you're putting it lightly.
>> Of course, first thing, without even reading it, is questioning the
>> relevance of such articles written by heavy proponents of
>> "alternative" languages. How much more biased can one be?
>>
>> Digging a bit deeper, there is nothing much to even take from this
>> short article. It's pretty shallow.
>>
>> - C is difficult to parse? C declarations are, for instance, not
>> exactly easy, but it's only very moderately difficult. You can have
>> fun with this to get an idea: https://cdecl.org/ . I has never made
>> it a problem to write a C compiler. There are more of them out there
>> than for any other language, I think. OTOH, there is, AFAIK, only one
>> implementation of Rust. Which to me is in itself a problem. I'm
>> curious to see if it ever even gets to the point of having other
>> competing implementations.
>
> It's probably referring to the typedef issue.
>
> In the absence of typedefs, type names consist of keywords and
> punctuation. A typedef (a feature that was added to the language
> after the syntax had been established) creates a type name that's an
> identifier. It's impossible to parse something that uses a typedef name
> without knowing that it's a typedef name. In effect a typedef adds a
> context-sensitive keyword to the grammar. The parser needs to query the
> symbol table.
>
> But it's a solved problem and not that big a deal.
>

Or, at least, you can't do it "properly" without knowing the typedefs.

But, heuristics exist, say we assume that:
identifier identifier;
identifier '*' identifier;
...

Are not valid in statement context, then one can assume by extension,
that encountering one of these patterns means to interpret the first
identifier as a type name.

In some cases, one can make an assumption regarding any preceding
keywords, and whether these keywords already define a type valid (as to
whether to parse an identifier as a typename or part of the declarator),
in combination with assuming the original cases to still be invalid (if
we see this, the identifier is parsed as a typename).

....

This will parse most code OK, but if one tries to use this as a general
strategy, it may trip up occasionally.

One major problem case is casts:
x=(foo)(1, 2);
If this is meant to be a function call, it may be parsed incorrectly if
'foo' is assumed to be a type. This situation does pop up occasionally
in the wild.

....

But, yeah, if one has a preprocessor, handles typedefs during parsing,
.... then parsing C correctly isn't all that difficult.

There may be other edge cases, as I recently encountered code that did
something like:
enum vals1 {
vals1a, vals1b, vals1c, ...
};
enum vals2 {
vals2a, vals2b=vals1c, ...
};

Which required adding a new table in this case to sort out enum parsing.

If designing a new language, would prefer to avoid a dependence on prior
context during parsing, but this is its own thing.

On 24/03/2022 19:16, Ben Bacarisse wrote:
> Richard Harnden <richard.nospam@gmail.com> writes:
>
>> "C: Everyone's favourite programming language isn't a programming language"
>>
>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>
> Is this a click bait article? The answer might surprise you!
>

Anything controversial always seems like clickbait to you! To me it just
seems that people finally saying what they've long thought.

Here's another recent article on the subject written more passionately,
which I suggest you don't click on either:

https://gankra.github.io/blah/c-isnt-a-language/

On 24/03/2022 17:55, Guillaume wrote:
> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>> Richard Harnden <richard.nospam@gmail.com> writes:
>>> "C: Everyone's favourite programming language isn't a programming
>>> language"
>>>
>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>
>> The article doesn't make a whole lot of sense - it's basically just
>> bitching because swift and rust can't do everything that C can.
>
> And you're putting it lightly.
> Of course, first thing, without even reading it, is questioning the
> relevance of such articles written by heavy proponents of "alternative"
> languages. How much more biased can one be?
>
> Digging a bit deeper, there is nothing much to even take from this short
> article. It's pretty shallow.
>
> - C is difficult to parse?

This might be within a context where C syntax is used to define an API
(eg. header files), then processing such files either manually or using
a tool can give rise to the issues mentioned.

You can't write a simple tool, you need to incorporate half of a C compiler.

C declarations are, for instance, not exactly
> easy, but it's only very moderately difficult. You can have fun with
> this to get an idea: https://cdecl.org/ .

The fact that such a tool even needs to exist isn't a giant red flag to you?

The whole point of having textual syntax in a program language is to
make it easier for humans! Needing a separate program to make sense of
it ... makes no sense.

On 24/03/2022 22:06, Bart wrote:
>
> Anything controversial always seems like clickbait to you!

You need to look at the background of people writing these articles. The
link you posted says this:

"I'm known for my work on Rust, Swift, and Homestuck."
<https://gankra.github.io/blah/>

That guy can never be objective about any other programming languages.
Probably he has given up learning new things about other programming
languages.

However, C does need to add libraries to make it do something else
without the users having to spend time writing their own or buying
bespoke services from others. C was created to enhance the Unix
operating System but it didn't go further than that. What now needs to
be done is to have libraries for databases, files, GUI etc like C# has done.

People should use whatever is quicker to get results. There is no point
in bashing about one particular programming language. Things have moved
on and more and more apps are run through a web browser!!. You can use
Word or Excel in any browser these days. C has failed to keep up with
this trend. How many people are still spending time enhancing an
operating system? People are writing Apps that can do something.

Bart <bc@freeuk.com> writes:

> On 24/03/2022 19:16, Ben Bacarisse wrote:
>> Richard Harnden <richard.nospam@gmail.com> writes:
>>
>>> "C: Everyone's favourite programming language isn't a programming language"
>>>
>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>> Is this a click bait article? The answer might surprise you!
>
> Anything controversial always seems like clickbait to you! To me it
> just seems that people finally saying what they've long thought.

Yes, I've read articles like that for decades. But they have to have
click-bait titles these days.

> Here's another recent article on the subject written more
> passionately, which I suggest you don't click on either:
>
> https://gankra.github.io/blah/c-isnt-a-language/

Thanks for the advice -- I have followed it to the letter.

--
Ben.

BGB <cr88192@gmail.com> writes:
> On 3/24/2022 1:36 PM, Keith Thompson wrote:
>> Guillaume <message@bottle.org> writes:
>>> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>>> "C: Everyone's favourite programming language isn't a programming language"
>>>>>
>>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>> The article doesn't make a whole lot of sense - it's basically just
>>>> bitching because swift and rust can't do everything that C can.
>>>
>>> And you're putting it lightly.
>>> Of course, first thing, without even reading it, is questioning the
>>> relevance of such articles written by heavy proponents of
>>> "alternative" languages. How much more biased can one be?
>>>
>>> Digging a bit deeper, there is nothing much to even take from this
>>> short article. It's pretty shallow.
>>>
>>> - C is difficult to parse? C declarations are, for instance, not
>>> exactly easy, but it's only very moderately difficult. You can have
>>> fun with this to get an idea: https://cdecl.org/ . I has never made
>>> it a problem to write a C compiler. There are more of them out there
>>> than for any other language, I think. OTOH, there is, AFAIK, only one
>>> implementation of Rust. Which to me is in itself a problem. I'm
>>> curious to see if it ever even gets to the point of having other
>>> competing implementations.
>> It's probably referring to the typedef issue.
>> In the absence of typedefs, type names consist of keywords and
>> punctuation. A typedef (a feature that was added to the language
>> after the syntax had been established) creates a type name that's an
>> identifier. It's impossible to parse something that uses a typedef name
>> without knowing that it's a typedef name. In effect a typedef adds a
>> context-sensitive keyword to the grammar. The parser needs to query the
>> symbol table.
>> But it's a solved problem and not that big a deal.
>
> Or, at least, you can't do it "properly" without knowing the typedefs.

I don't know what distinction you're making. I said that C cannot be
parsed without recognizing typedefs.

> But, heuristics exist, say we assume that:
> identifier identifier;
> identifier '*' identifier;
> ...
>
> Are not valid in statement context, then one can assume by extension,
> that encountering one of these patterns means to interpret the first
> identifier as a type name.

The latter assumption is invalid. For example:

int main(void) {
int x=0, y=0;
x * y;
{
typedef int x;
x * y;
}
}

The two lines "x * y;" are textually identical. The first is an
expression statement containing a multiplicative expression. The second
defines an object y of type int*. A parser cannot distinguish between
these two interpretations without knowing that x has been declared as a
typedef in the inner scope. (This applies equally in C90, which did not
allow mixing declarations and statements.)

A C parser that makes "assumptions" without already knowing which
identifiers are defined as typedefs in the current scope is not a valid
C parser. It's annoying, but as I said, it's a solved problem -- and
it's only a problem if you're writing a C parser.

And I've never heard of a C compiler that doesn't get this right.

> In some cases, one can make an assumption regarding any preceding
> keywords, and whether these keywords already define a type valid (as
> to whether to parse an identifier as a typename or part of the
> declarator), in combination with assuming the original cases to still
> be invalid (if we see this, the identifier is parsed as a typename).
>
> ...
>
> This will parse most code OK, but if one tries to use this as a
> general strategy, it may trip up occasionally.
>
> One major problem case is casts:
> x=(foo)(1, 2);
> If this is meant to be a function call, it may be parsed incorrectly
> if 'foo' is assumed to be a type. This situation does pop up
> occasionally in the wild.

Again, no assumption is necessary or sufficient. The parser has to know
whether "foo" is a type name or not.

> ...
>
>
>
> But, yeah, if one has a preprocessor, handles typedefs during parsing,
> ... then parsing C correctly isn't all that difficult.

This has nothing to do with the C preprocessor.

> There may be other edge cases, as I recently encountered code that did
> something like:
> enum vals1 {
> vals1a, vals1b, vals1c, ...
> };
> enum vals2 {
> vals2a, vals2b=vals1c, ...
> };
>
> Which required adding a new table in this case to sort out enum parsing.

The expression on the RHS of "vals2b=..." can be any integer constant
expression. The fact that it happens to be an enumeration constant is
irrelevant, and is not a problem for parsing.

> If designing a new language, would prefer to avoid a dependence on
> prior context during parsing, but this is its own thing.

Agreed. If the idea that an identifier can be a type name had been
introduced to the language earlier, the syntax could have been designed
to avoid the typedef problem.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 24/03/2022 22:41, Jack Noddy wrote:
> On 24/03/2022 22:06, Bart wrote:
>>
>> Anything controversial always seems like clickbait to you!
>
> You need to look at the background of people writing these articles. The
> link you posted says this:
>
> "I'm known for my work on Rust, Swift, and Homestuck."
> <https://gankra.github.io/blah/>
>
> That guy can never be objective about any other programming languages.
> Probably he has given up learning new things about other programming
> languages.
>
> However, C does need to add libraries to make it do something else
> without the users having to spend time writing their own or buying
> bespoke services from others. C was created to enhance the Unix
> operating System but it didn't go further than that. What now needs to
> be done is to have libraries for databases, files, GUI etc like C# has done.
>
> People should use whatever is quicker to get results. There is no point
> in bashing about one particular programming language. Things have moved
> on and more and more apps are run through a web browser!!. You can use
> Word or Excel in any browser these days. C has failed to keep up with
> this trend. How many people are still spending time enhancing an
> operating system? People are writing Apps that can do something.
>

I take it that you also run your C compiler via a web app!

People are still writing programs at a lower level that make use, on
Windows, of external libraries supplied as DLL shared libraries. (There
are 50,000 DLL files on my Windows machine.)

Those DLLs invariably have C-like APIs, except where they use C++, and
they invariably contain functions called via the platform ABI, which is
full of lower-level data types just as are used in C.

It's the chaotic way that C expresses those types in APIs that is one of
the complaints.

So the beef in this short article is not so much in having such
low-level interfaces at all, but the less-than-ideal way in which C has
become the lingua franca for expressing them.

The answer isn't to simply do away with vast libraries like GTK, or
finding another way to talk to the Windows OS, and just use a
batteries-included scripting language.

On 3/24/2022 6:11 PM, Keith Thompson wrote:
> BGB <cr88192@gmail.com> writes:
>> On 3/24/2022 1:36 PM, Keith Thompson wrote:
>>> Guillaume <message@bottle.org> writes:
>>>> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>>>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>>>> "C: Everyone's favourite programming language isn't a programming language"
>>>>>>
>>>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>>> The article doesn't make a whole lot of sense - it's basically just
>>>>> bitching because swift and rust can't do everything that C can.
>>>>
>>>> And you're putting it lightly.
>>>> Of course, first thing, without even reading it, is questioning the
>>>> relevance of such articles written by heavy proponents of
>>>> "alternative" languages. How much more biased can one be?
>>>>
>>>> Digging a bit deeper, there is nothing much to even take from this
>>>> short article. It's pretty shallow.
>>>>
>>>> - C is difficult to parse? C declarations are, for instance, not
>>>> exactly easy, but it's only very moderately difficult. You can have
>>>> fun with this to get an idea: https://cdecl.org/ . I has never made
>>>> it a problem to write a C compiler. There are more of them out there
>>>> than for any other language, I think. OTOH, there is, AFAIK, only one
>>>> implementation of Rust. Which to me is in itself a problem. I'm
>>>> curious to see if it ever even gets to the point of having other
>>>> competing implementations.
>>> It's probably referring to the typedef issue.
>>> In the absence of typedefs, type names consist of keywords and
>>> punctuation. A typedef (a feature that was added to the language
>>> after the syntax had been established) creates a type name that's an
>>> identifier. It's impossible to parse something that uses a typedef name
>>> without knowing that it's a typedef name. In effect a typedef adds a
>>> context-sensitive keyword to the grammar. The parser needs to query the
>>> symbol table.
>>> But it's a solved problem and not that big a deal.
>>
>> Or, at least, you can't do it "properly" without knowing the typedefs.
>
> I don't know what distinction you're making. I said that C cannot be
> parsed without recognizing typedefs.
>

Note I said "properly", one can do it, sorta, but may get incorrect
results. For the most part, these results *may* be sufficient for some
tasks which are a little looser in terms of their requirements.

In this case, one can ignore the existence of cases where the parser
will fall on its face (they will still exist, but we can pretend they
don't exist...).

>> But, heuristics exist, say we assume that:
>> identifier identifier;
>> identifier '*' identifier;
>> ...
>>
>> Are not valid in statement context, then one can assume by extension,
>> that encountering one of these patterns means to interpret the first
>> identifier as a type name.
>
> The latter assumption is invalid. For example:
>
> int main(void) {
> int x=0, y=0;
> x * y;
> {
> typedef int x;
> x * y;
> }
> }
>
> The two lines "x * y;" are textually identical. The first is an
> expression statement containing a multiplicative expression. The second
> defines an object y of type int*. A parser cannot distinguish between
> these two interpretations without knowing that x has been declared as a
> typedef in the inner scope. (This applies equally in C90, which did not
> allow mixing declarations and statements.)
>
> A C parser that makes "assumptions" without already knowing which
> identifiers are defined as typedefs in the current scope is not a valid
> C parser. It's annoying, but as I said, it's a solved problem -- and
> it's only a problem if you're writing a C parser.
>
> And I've never heard of a C compiler that doesn't get this right.
>

Granted.

But, the context in this case was for parsing for things like FFI tools,
rather than necessarily for a C compiler. Namely, if you want to parse
headers without needing to do so via an actual C compiler.

For a C compiler, trying to do it this way will result in incorrectly
parsing things on occasion. I was not trying to claim that it wouldn't;
rather you would have a variant that would not allow for things like
having a multiplication expression where a statement was expected.

And, OTOH, for something like "mine program for prototypes to put into a
header" or similar, one can get "even more tacky" (eg, using textual
pattern matching to grab anything that looks like a function
declaration, *).

*: And then using annotation comments to tell the tool when to ignore
any "false positives".

>> In some cases, one can make an assumption regarding any preceding
>> keywords, and whether these keywords already define a type valid (as
>> to whether to parse an identifier as a typename or part of the
>> declarator), in combination with assuming the original cases to still
>> be invalid (if we see this, the identifier is parsed as a typename).
>>
>> ...
>>
>> This will parse most code OK, but if one tries to use this as a
>> general strategy, it may trip up occasionally.
>>
>> One major problem case is casts:
>> x=(foo)(1, 2);
>> If this is meant to be a function call, it may be parsed incorrectly
>> if 'foo' is assumed to be a type. This situation does pop up
>> occasionally in the wild.
>
> Again, no assumption is necessary or sufficient. The parser has to know
> whether "foo" is a type name or not.
>

To be "correct".

Requirements are looser if:
It doesn't need to always parse correctly;
It doesn't need to deal with "general purpose" code;
...

So, it is not valid for a general purpose compiler, but may be
sufficient for FFI tools or similar.

It may still need to at least attempt to parse function bodies though,
because these are semi-common inside headers.

Granted, one can argue as well that maintaining a table of previously
seen typedefs isn't all that difficult, and is required for correct parsing.

One could potentially have a language which has the "look and feel" of
C, but uses a different parsing strategy, and leave it as the
programmers' issue if they write something and it doesn't work as expected.

>> ...
>>
>>
>>
>> But, yeah, if one has a preprocessor, handles typedefs during parsing,
>> ... then parsing C correctly isn't all that difficult.
>
> This has nothing to do with the C preprocessor.
>

One still needs a preprocessor for "#include" and "#ifdef" and similar,
to be able to make much useful sense of the contents of most C headers
for FFI tools.

>> There may be other edge cases, as I recently encountered code that did
>> something like:
>> enum vals1 {
>> vals1a, vals1b, vals1c, ...
>> };
>> enum vals2 {
>> vals2a, vals2b=vals1c, ...
>> };
>>
>> Which required adding a new table in this case to sort out enum parsing.
>
> The expression on the RHS of "vals2b=..." can be any integer constant
> expression. The fact that it happens to be an enumeration constant is
> irrelevant, and is not a problem for parsing.
>

It depends some on when and where the values are assigned in the "enum".
In this case, the enums were handled fairly early in the process, so
ended up needing another table mostly to deal with values for things
like "enum" and "const int x=whatever;" and similar, so that these
values could be propagated at a fairly early stage (namely during
parse-time constant-folding operations).

Things like dealing with global variables and functions would not happen
until a following stage.

>> If designing a new language, would prefer to avoid a dependence on
>> prior context during parsing, but this is its own thing.
>
> Agreed. If the idea that an identifier can be a type name had been
> introduced to the language earlier, the syntax could have been designed
> to avoid the typedef problem.
>

Yeah.

Languages like C# seem to be built around a strategy more like I had
mentioned earlier.

Le 25/03/2022 à 00:11, Keith Thompson a écrit :
> The latter assumption is invalid. For example:
>
> int main(void) {
> int x=0, y=0;
> x * y;
> {
> typedef int x;
> x * y;
> }
> }
>
> The two lines "x * y;" are textually identical. The first is an
> expression statement containing a multiplicative expression. The second
> defines an object y of type int*. A parser cannot distinguish between
> these two interpretations without knowing that x has been declared as a
> typedef in the inner scope. (This applies equally in C90, which did not
> allow mixing declarations and statements.)

Yep. All it requires is to look up in a symbol table though. Not a huge
deal. The potential deal is that it's a bit slower to parse, then. (But
languages that do not need to do this will just postpone it until later.)

For any "modern" language, that is usually much more complex than C,
having to look up type definitions in a table is frankly a completely
minor point.

The more important point is whatever is more readable. And I'll have to
admit that the "wirthian" (Pascal-like) approach is more readable.

As the site I linked to shows, you can write pretty convoluted C
declarations that are basically impossible to figure out in a reasonable
time by a human. Doesn't mean you have to do it, though.

On 3/24/22 10:35, Richard Harnden wrote:
> "C: Everyone's favourite programming language isn't a programming language"
>
> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

Incoherent drivel.

--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================

On 3/24/2022 11:40 PM, Bart wrote:
> On 24/03/2022 17:55, Guillaume wrote:
>> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>> "C: Everyone's favourite programming language isn't a programming
>>>> language"
>>>>
>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>
>>> The article doesn't make a whole lot of sense - it's basically just
>>> bitching because swift and rust can't do everything that C can.
>>
>> And you're putting it lightly.
>> Of course, first thing, without even reading it, is questioning the
>> relevance of such articles written by heavy proponents of
>> "alternative" languages. How much more biased can one be?
>>
>> Digging a bit deeper, there is nothing much to even take from this
>> short article. It's pretty shallow.
>>
>> - C is difficult to parse?
>
> This might be within a context where C syntax is used to define an API
> (eg. header files), then processing such files either manually or using
> a tool can give rise to the issues mentioned.
>
> You can't write a simple tool, you need to incorporate half of a C
> compiler.
>
>  C declarations are, for instance, not exactly
>> easy, but it's only very moderately difficult. You can have fun with
>> this to get an idea: https://cdecl.org/ .
>
> The fact that such a tool even needs to exist isn't a giant red flag to
> you?
>
> The whole point of having textual syntax in a program language is to
> make it easier for humans! Needing a separate program to make sense of
> it ... makes no sense.
>

I see your point, but...

Considering that the C syntax was designed in the '70s, it might be
possible that it could have been made better, but look at what other
languages have been doing "better"

First, look at C's flexibility with pointers, which is one of the strong
suits of C (in fact, it's a must have, something that makes C really
good for some kind of programming):
C allows you to declare a pointer to pointer to pointer to function
returning a pointer to function returning a pointer to int.

Now, good luck doing that with Java.

More in general, it is about indirection. If a language's declaration
syntax allows for any combination of indirection constructs, then things
may get convoluted, but it's the type itself that is convoluted, not
necessarily the syntax's fault.

And, obviously, typedefs make things a /lot/ easier.

> First, look at C's flexibility with pointers, which is one of the strong
> suits of C (in fact, it's a must have, something that makes C really
> good for some kind of programming):
> C allows you to declare a pointer to pointer to pointer to function
> returning a pointer to function returning a pointer to int.

And that's sufficient for you for assessing a language as powerful ???
C is for sure not a powerful language but is very rudiemental.

On 25/03/2022 18:17, Manfred wrote:
> On 3/24/2022 11:40 PM, Bart wrote:
>> On 24/03/2022 17:55, Guillaume wrote:
>>> Le 24/03/2022 à 16:45, Scott Lurndal a écrit :
>>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>>> "C: Everyone's favourite programming language isn't a programming
>>>>> language"
>>>>>
>>>>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>>>>
>>>> The article doesn't make a whole lot of sense - it's basically just
>>>> bitching because swift and rust can't do everything that C can.
>>>
>>> And you're putting it lightly.
>>> Of course, first thing, without even reading it, is questioning the
>>> relevance of such articles written by heavy proponents of
>>> "alternative" languages. How much more biased can one be?
>>>
>>> Digging a bit deeper, there is nothing much to even take from this
>>> short article. It's pretty shallow.
>>>
>>> - C is difficult to parse?
>>
>> This might be within a context where C syntax is used to define an API
>> (eg. header files), then processing such files either manually or
>> using a tool can give rise to the issues mentioned.
>>
>> You can't write a simple tool, you need to incorporate half of a C
>> compiler.
>>
>>   C declarations are, for instance, not exactly
>>> easy, but it's only very moderately difficult. You can have fun with
>>> this to get an idea: https://cdecl.org/ .
>>
>> The fact that such a tool even needs to exist isn't a giant red flag
>> to you?
>>
>> The whole point of having textual syntax in a program language is to
>> make it easier for humans! Needing a separate program to make sense of
>> it ... makes no sense.
>>
>
> I see your point, but...
>
> Considering that the C syntax was designed in the '70s, it might be
> possible that it could have been made better, but look at what other
> languages have been doing "better"
>
> First, look at C's flexibility with pointers, which is one of the strong
> suits of C (in fact, it's a must have, something that makes C really
> good for some kind of programming):
> C allows you to declare a pointer to pointer to pointer to function
> returning a pointer to function returning a pointer to int.
>
> Now, good luck doing that with Java.

I don't know Java or its limitations. But Algol68 for example came out
before C, and it allowed arbitrarily complex type chains like your
example, yet it used left-to-right syntax, with any name at one end,
rather than in the middle.

My languages do the same, and actually one of them can express your
example like this, almost identical to your English version:

pointer to pointer to pointer to function returning pointer to
function returning pointer to int p

This was a bit of fun where 'pointer' was a synonym for 'ref', 'to' is
ignored, and 'returning' means '=>' as it would generally written like this:

ref ref ref function => ref function => ref int q

As for C, I believe the equivalent is:

int *(*(***q)(void))(void);

If I wanted to declare p, q, r of the same type, then while /I/ can write:

ref ref ref function => ref function => ref int p, q, r

In C it would need to be:

int *(*(***p)(void))(void), *(*(***q)(void))(void),
*(*(***r)(void))(void);

I would need this to avoid repetition:

typedef *(*(***dummyT)(void))(void),
dummyT p, q, r

So you need to invent some name that describes this particular function
signature compared with all others (notice it is still in the middle!).

It's a joke.

>
> More in general, it is about indirection. If a language's declaration
> syntax allows for any combination of indirection constructs, then things
> may get convoluted, but it's the type itself that is convoluted, not
> necessarily the syntax's fault.
>
> And, obviously, typedefs make things a /lot/ easier.

Typedefs should be used when they make sense for the project. If used to
just to mitigate the awfulness of the type syntax, then something is wrong.

You don't want to do so just to ensure you are declaring the correct
type here:

int *A[10];
int (*B)[10];

(Since, in C, you will not get an error if you would normally type *A[i]
and (*B)[i], but accidentally do (*A)[i] and *B[i].)

Now go and look at some parameter declarations (such as in APIs), where:

int A[10]; // In a parameter list
int A[10]; // anywhere else

declare quite different types.

LOL, this is all FUD people is been attacking C since I was born

On 2022-03-24, Richard Harnden <richard.nospam@gmail.com> wrote:
> "C: Everyone's favourite programming language isn't a programming language"
>
> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

--
https://hispagatos.org
Gemini://rek2.hispagatos.org
https://hispagatos.space/@rek2
https://portal.mozz.us/gemini/rek2.hispagatos.org/

Exactly
claps

Happy Hacking
On 2022-03-24, Scott Lurndal <scott@slp53.sl.home> wrote:
> Richard Harnden <richard.nospam@gmail.com> writes:
>>"C: Everyone's favourite programming language isn't a programming language"
>>
>>Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>
> The article doesn't make a whole lot of sense - it's basically just
> bitching because swift and rust can't do everything that C can.

--
https://hispagatos.org
Gemini://rek2.hispagatos.org
https://hispagatos.space/@rek2
https://portal.mozz.us/gemini/rek2.hispagatos.org/

On Friday, 25 March 2022 at 18:20:16 UTC, Bonita Montero wrote:
> > First, look at C's flexibility with pointers, which is one of the strong
> > suits of C (in fact, it's a must have, something that makes C really
> > good for some kind of programming):
> > C allows you to declare a pointer to pointer to pointer to function
> > returning a pointer to function returning a pointer to int.
> And that's sufficient for you for assessing a language as powerful ???
> C is for sure not a powerful language but is very rudiemental.
>
Indirection is one of the most powerful concepts in programming.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 25 March 2022 at 18:20:16 UTC, Bonita Montero wrote:
>> > First, look at C's flexibility with pointers, which is one of the strong
>> > suits of C (in fact, it's a must have, something that makes C really
>> > good for some kind of programming):
>> > C allows you to declare a pointer to pointer to pointer to function
>> > returning a pointer to function returning a pointer to int.
>> And that's sufficient for you for assessing a language as powerful ???
>> C is for sure not a powerful language but is very rudiemental.
>>
> Indirection is one of the most powerful concepts in programming.

What he said ;-)

--
Ben.

Le 25/03/2022 à 00:10, Ben Bacarisse a écrit :
>> Here's another recent article on the subject written more
>> passionately, which I suggest you don't click on either:
>>
>> https://gankra.github.io/blah/c-isnt-a-language/
>
> Thanks for the advice -- I have followed it to the letter.

You were well inspired. I had a look and it's even worse than the other
article. It just looks like a kiddo throwing a tantrum while desperately
trying to sound smart.