Path: ...!2.eu.feeder.erje.net!feeder.erje.net!nntp.comgw.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Thu, 12 Dec 2024 02:31:21 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vjdhtn$1hp82$1@paganini.bofh.team>
References: <vi54e9$3ie0o$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> <slrnvlik4j.ns4.ike@iceland.freeshell.org> <vjcb2s$1jcad$4@dont-email.me> <vjcfls$1ki9v$1@dont-email.me>
Injection-Date: Thu, 12 Dec 2024 02:31:21 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="1631490"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3699
Lines: 48

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 11.12.2024 16:28, David Brown wrote:
>> On 11/12/2024 09:43, Ike Naar wrote:
>>> On 2024-12-09, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>>
>>>> An unambiguous grammar is something quite essential; [...]
>>>
>>> [ dangling-else sample ]
>> 
>> Given that the resolution is in the "semantics" section rather than the
>> "syntax" section, it might seem like a grammatical ambiguity.  But I
>> don't think it is, technically - the syntax rules say that the set of
>> tokens making up "if (E1) if (E2) S1 else S2" are valid syntax.  It is
>> up to the semantics to determine what the code will do here.  (And the
>> semantics are unambiguous.)
> 
> I'm a bit ambivalent about that. - Yes, technically it's syntax, it's
> syntactically probably correct, and it has a semantical ambiguity that
> needs to be resolved. All languages with the dangling-else property do
> resolve that. But the syntax could have been defined in a way that such
> that a dangling else cannot appear in the first place. (Not in "C" and
> descendant languages, of course; that ship has sailed.)

Of course nobody is going to retroactively change C standards.
However, it is well-known how to rewrite grammar so that there
is no "dangling else" ambiguity in the grammar and resulting
parse trees are equivalent to parse trees produced by the current
grammar.  Drawback of such rewrite is that grammar is significantly
bigger, basically most things that can appear iside 'if' must
come in two versions.  Such grammar is harder to understand,
so most languages make pragmatic choice of using simpler grammar
+ extra rule.  And this simpler grammar can be fed into a parser
generator to get parser which resolves "dangling else" as
proscribed by the rule and such parser is likely to be smaller
and more efficient than parser for grammar with conflict
removed.

So, while "dangling else" problem is rather fundamental, using
ambigious grammar is a pragmatic choice.

The other things that I mentioned (type name trouble) is more
problematic: trying to fix it leads to grammar that is not
LR(1).  I think that this grammar is unambigious, but it
would not work with standard parser generators ("dangling else"
rewrite preserves good propeties of grammar and only affects
size).

-- 
                              Waldek Hebisch