The declarator looks complex because of differences in the precedence and associativity between the asterisk, `[]` and `()` operators. The point is that the language uses a set of the same operators with the same precedence and associativity both in declarations and in normal expressions.

In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.

I'm guessing you mean `array[10] of pointer to int`.

This is pretty close to Pascal syntax already: `array[0..9] of ^Integer`, where ^ is pronounced 'pointer to'.

Pascal is a language that is genuinely easy to parse; it's designed to be LL(1). C is not; in particular, typedefs effectively introduce keywords, and the easiest way to parse C is to inform the tokenizer about typedefs as they're found so the parser can disambiguate things like `a (b);`; this looks simultaneously like declaring a variable and calling a function, depending on the type of 'a'.

Maybe I'm missing something, but I think Pascal "TYPE" blocks and C "typedef" statements do pretty much the same thing.

(they don't look the same, but you can use either to define record/structure types or enums, for example)

The distinction is in the syntax.

    int main()
    {
       foo(bar);
       foo * bar;
    }

If foo is a typedef, these are variable declarations, otherwise the first is a function call and the second multiplication (syntactically). These are different kinds of things that would normally be up to the parser to figure out (rather than semantic analysis later). These are well-known ambiguities relating to typedefs in C (well-known to compiler authors, at any rate).

The situation doesn't come up in Pascal because variables go in the var block (starting with the 'var' keyword) and functions and procedures both start with keywords ('function' and 'procedure').

OK, thanks. I was focusing on the "definition" part, rather than the "usage" part of the types.

It never occurred to me to put variables names inside parens in a declaration when I did C, though. But OF COURSE it's legal obfuscation.

As stated elsewhere, I don't know why C had to screw up Algol's syntax so badly. I guess K&R liked curly braces much more than BEGIN/END, and why stop there, once you get going. Maybe somebody had a love affair with APL???

> The point is that the language uses a set of the same operators with the same precedence and associativity both in declarations and in normal expressions.

Using the same precedence and associativity in declarations and normal expressions doesn't really help the compiler writer though, so I'm not sure how this supports your point. If anything, it complicates the parser by making it harder to decide if a given sequence of tokens is a declaration or an expression (e.g. the classic "a * b;" problem).

> In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.

It sounds like you're saying that C's type syntax isn't easier to read than other, similar, possible syntaxes. On that, I completely agree (in fact, I think C's type syntax is horrendous). However, that's orthogonal to the issue of Dennis Ritchie's original intent when designing C. From his writings at least, it seems like he wanted to make it easy for the programmer to reason about the syntax and I'd even argue that he took steps to complicate the compiler to accommodate his chosen syntax. I'd also argue that he failed horribly in accomplishing his intention and the syntax you're describing would have been much easier to read.

There is a remark in Fraser & Hansen's LCC book noting how complicated C declarations are to parse because type information is spread out through the declaration. You can see it in your example. Inside the compiler, you'd parse that to something like [VAR arr [ARRAY [* INT] 10]. But to get there you're doing something like: "oh what follows is an INT, no it's a pointer to an int, it's named 'arr', oh fuck it's actually an array of 10 pointers to int."

OR, it would look like "decorate a semantic tree until the declaration is complete. Now, what do we have? An array of pointers to int. Fine."

Yeah, I don't know what these fools are complaining about. You put up a struct, parse the whole statement into it. Doesn't seem so tough to me.

You can't put up a struct because the structure of a C type is arbitrarily complex. E.g. Multiple levels of pointers. So you have to maintain a type as some sort of tree, and then as you're parsing it you have to fill in the right parts of the tree.

Not rocket science, obviously, but the original statement was that C types were designed to be easy to parse, which clearly isn't true. If the types were prefix or postfix, it'd be trivial to build the trees in a recursive descent parser.

Is it arbitrarily complex? Maybe nested array types, but every other type can be expressed with an indirection count, and a leaf type. That said, if it can't go in a struct, it can easily go in a linked list with the same information for each level of indirection.

What about function types? That alone gets you to "tree" complexity.

You get used to anything. I find that example no better.

And remember declarations can be arbitrarily complex. How do you declare a pointer to arrays of pointers to pointers to arrays? In free prose.