Path: news.eternal-september.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Thu, 12 Dec 2024 12:11:11 +0000
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <vjejsv$23rfd$2@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me>
 <87plmfu2ub.fsf@nosuchdomain.example.com> <vi9jk4$gse4$1@dont-email.me>
 <vi9kng$gn4c$1@dont-email.me> <87frnbt9jn.fsf@nosuchdomain.example.com>
 <viaqh0$nm7q$1@dont-email.me> <877c8nt255.fsf@nosuchdomain.example.com>
 <viasv4$nm7q$2@dont-email.me> <vibr1l$vvjf$1@dont-email.me>
 <vic73f$1205f$1@dont-email.me> <20241129142810.00007920@yahoo.com>
 <vicfra$13nl4$1@dont-email.me> <20241129161517.000010b8@yahoo.com>
 <vicque$15ium$2@dont-email.me> <vid110$16hte$1@dont-email.me>
 <vifcll$1q9rj$1@dont-email.me> <vifiib$1s07p$1@dont-email.me>
 <87ldwx10gv.fsf@bsb.me.uk> <vimtt4$27vv$1@dont-email.me>
 <86ser1kgp5.fsf@linuxsc.com> <vit69t$1qfgg$1@dont-email.me>
 <87ldwtzlc0.fsf@nosuchdomain.example.com> <vitjgg$1tukq$2@dont-email.me>
 <vj1bss$325uo$1@dont-email.me> <vj1h4i$335q1$2@dont-email.me>
 <vj1mhi$34p7h$1@dont-email.me> <vj1prj$35je4$1@dont-email.me>
 <vj7dup$he7i$1@dont-email.me> <vjasuj$17uod$1@dont-email.me>
 <vjcebq$1ka5o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Dec 2024 13:11:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="021d91925d3f1b965194e346b20c998a";
	logging-data="2223597"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18wFCV6sixrZ2rP7C0PNaUI"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:u75H7wwRNYoQysLiY8kVaEMkwIE=
In-Reply-To: <vjcebq$1ka5o$1@dont-email.me>
Content-Language: en-GB

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.