Re: question about linker

On 14/12/2024 20:17, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

>
OK, if it's so simple, explain it to me.
>
Apparently the first line here needs a semicolon after }, the second
doesn't:
>
   int X[1] = {0};
   void Y() {}
>
Similarly here:
>
   if (x) y;
   if (x) {}
>
Why?
>
"Because that's what the grammar says" isn't a valid answer.

 In first approximation, for some constructs it is clear where
the end is, so no need for semicolon, for some other semicolon
is needed to mark the end.  This rule does no work in all cases,
for example 'continue' and 'break' are keywords and defining
corresponding statements without semicolon would lead to
no ambiguity.  Similarly in case of 'goto'.  'return' is
more tricky, but is seems that one could define it without
semicolon.  But here probably consistency won: 'break',
'contunue', 'goto' statement, 'return' statement are perceived
as simple statements and are covered by informal rule
"simple statement needs terminationg semicolon".  '{}'
is a compound statement, hence not a simple statement.
Similarly, 'if' is a complex statement, and needs no semicolon
on its own.  As you noted without terminating semicolon do-while
loop would be ambigious, so it needs semicolon.  I do
not have example for declarations, but I suspect that defining
then without semicolon would be ambigious.  Function
_definition_ is anambigious without terminating semicolon,
so why put is there.

For the same reason that f(1 2 3) might be unambiguous, as usually it's written f(1, 2, 3).
Actually, since C likes to declare/define lists of things where other languages don't allow them, such as:
  typedef int T, U, *V;
  struct tag {int x;} a, b, c;
  enum {red, green} blue, yellow;
I couldn't quite see why you can't do the same with functions:
  int F(void){return 1;}, G(void){return 2;}

 Concerning "grammar says it", grammar for C90 from which one
can generate working parser has 74 nonterminals.  You could
change some rules and still get working parser for a different
language.  So in this sense part of grammar is purely
arbitrary.  But other changes would lead to grammar that
fails to work.  If you look at rules you will see
substantial similarities between some rules, so grammar
is really simpler than what size alone would would suggest.
So, having working and sane (that is relatively simple)
grammar puts restrictions on the language, some changes
simply do not fit.  Some changes would lead to completely
different language, that was not an option for C, as
very first versions were intentionaly similar to earlier
languages and later there was a body of existing programs
and programmers.
 You write about confusion.  I think that what you present
grammarians would call "garden paths", that is perceiving/
trying to make up different rules than grammar rules.  In
your 'if' example you ignore simple thing: 'if' needs no
terminator on its own.

Now that you mention it, why not? In:
   if (c) s1; else s2;
s1 and s2 are statements, but so is the whole if-else construct; why doesn't that need its own terminator?
This is legal in C: {}{}{}{}.
As I said, I wouldn't be able to explain it.

It is null statement that needs
terminating semicolon, and "empty" compound statement that
does not need a terminator.  Null statement and compound
statement are quite different, in particular without
semicolon you would not know that null statement is there,

Identifying the end of /some/ statements shouldn't mean not needing terminators in those cases. It needs to be a consistent rule.

while compound statement can be easily recognized without
need for terminator.  There is no special rule for "if with
null statement", if it were you would get needlessly complex
grammar.
 In the first pair, one line is a declaration, another is
function definition.  Again, quite different constructs,
one needing terminator, other not needing it.
 Garden paths are common in natural language and people
cope quite well.  So for normal (even beginer)
programmers garden paths are not a real problem: you get
confused once, learn the right way and go on.  In many
cases learning is unconcious, you simply get used to
the way code is written, and when you make mistakes
compiler tells you that there is an error, so you
correct it.

But the exact rules remain fuzzy.
I wondered if my syntaxes are any better. There, first it is necessary to consider programs written on one line, since auto-semicolon-insertion would confuse matters.
Then, notionally, declarations, definitions, expressions and statements are all separated with a semicolon.
In some cases, because I haven't been rigorous, one can be missed out, and it still works. But that would be an oversight in the parser. (And usually, the two parts would be separated by a newline, which turns into a semicolon.)
The rule in the language (and in the grammar if I had one) is clear:
   if c then s1 else s2 fi
Here no ";" are needed, as at each level of statement, there is only one expression or statement; nothing to separate. Here:
   if c;d then s1;s2 else s2;s3 fi; if e then s4 fi
that ";" in "fi;" is needed to separate this statement from the next, even though you could probably figure out that the statement ends there.
(Note the "c;d" is not an error.) Another example with function defs, although I never write them like this:
   proc F = end; proc G = end
So, in this language, it is clear and consistent. Explaining why the multi-line version can leave the semicolons out is harder:
     if c
        d
     then
         s1
         s2
     else
         s2
         s3
     fi
     if
         e
     then
         s4
     fi
(If I was going to attempt a formal grammar, I'd try and make semicolon injection part of the lexer. Then the parser would always see the semicolons it needs.)