Re: question about linker

On 11/12/2024 16:24, Janis Papanagnou wrote:

On 11.12.2024 03:21, bart wrote:

On 09/12/2024 18:46, Janis Papanagnou wrote:
>

An unambiguous grammar is something quite essential; how would you
parse code if it were ambiguous?

>
You can easily parse a language in an ambiguous syntax. [...]

 Sure; I recall Fortran had such an ambiguity, I think it was in
context of FOR loops (something with the assignment and commas,
IIRC). - Whether it's "easily [to] parse" is arguable, though,
and certainly depends. - But I don't recall to have seen scary
things like that in any other language I had to do with.
 Experienced language developers wouldn't define an ambiguous
syntax in the first place. So what do you think your statement
contributes to desire to have an "unambiguous syntax"?
 I mean, if you get confused by an unambiguous syntaxes already,
what do you think happens with people if they have to program
in or understand an ambiguous language!
 

>

You postulate it as if the grammar were convoluted;

>
My opinion is that it is. Especially its propensity for using
long-winded production terms that look confusingly similar. (Would it
have killed somebody to make the names more distinct?)

 (I won't comment on your opinion.)
 With respect to distinctness of names I thought we had already
exchanged some words - remember my 'while' and 'until' samples
from Pascal (that somehow offended you)?

The names I'm talking about aren't terminals, they're ones like '*declaration' and '*declarator', or 'multiplicative-expression'.

 Concerning "C"; I don't see why you shouldn't name a "positive"
conditioned control construct consistently(!) as 'while' whether
it controls a loop entry or a loop exit, and to name a "negative"
conditioned control construct consistently(!) as 'until'.

I sometimes use 'when' for positive rather than 'if', and 'until' or 'unless' for negative.
(Or just use a 'not' prefix for negative, but for this purposes, it's more helpful it having low precedence rather than high, to avoid parentheses around the whole thing.)
One reason for using 'when' in some contexts is when 'if' could appear ambiguous (here I'm talking about my syntax);
    return if x=y             # conditional return from procedure
    return if a then b else c fi if x=y  # cond ret from function
I can't tell when 'if' after 'return' is forming a conditional return, or is part of the return value. Knowing if this is a function or procedure would help, but I considered that not strong enough.
It is not obvious, and can mask errors: did I want a conditional return, but I forgot the return value?
Instead I use:
    return when x=y
    return if a then b else c fi when x=y
    return unless x=y            # reverse logic
So here I put a little more thought into than just saying it is technically unambiguous.