Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Wed, 4 Dec 2024 02:22:46 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <20241203181358.493@kylheku.com>
References: <vi54e9$3ie0o$1@dont-email.me> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnuj$1aned$1@dont-email.me> <87ttbpqzm1.fsf@nosuchdomain.example.com>
 <vie0j5$1g968$1@dont-email.me> <vieun5$1mcnr$3@dont-email.me>
 <vihamj$2cflq$1@dont-email.me> <vihili$2f79m$1@dont-email.me>
 <vihu63$2ipg0$1@dont-email.me> <vii3kq$2kmc8$1@dont-email.me>
 <vikqvf$3fhce$1@dont-email.me> <jNm3P.7909$XuU6.3431@fx40.iad>
 <vinkbv$8r4i$1@dont-email.me> <vinm3p$9auh$1@dont-email.me>
 <vinqt2$bede$1@dont-email.me>
Injection-Date: Wed, 04 Dec 2024 03:22:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b7a9259e5b612f3710977eb63dcab0eb";
	logging-data="523848"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19WtSfdqvBzYFIfTzFWftJGs86s668SlLQ="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:hkljHjK884u8Yrx4E5pIjfnM2c4=
Bytes: 3183

On 2024-12-03, BGB <cr88192@gmail.com> wrote:
> On 12/3/2024 1:27 PM, Janis Papanagnou wrote:
>> On 03.12.2024 19:57, BGB wrote:
>>> On 12/2/2024 12:13 PM, Scott Lurndal wrote:
>>>>
>>>> Indeed.  One wonders at Bart's familiarity with formal grammars.
>>>
>>> In my case, personally I haven't encountered much that doesn't work well
>>> enough with a recursive-descent parser.
>> 
>> Is that meant as a contradiction? - If so, how?
>> 
>
> Formal grammars and parser generators aren't usually necessary IME, 
> since recursive descent can deal with most everything (and is generally 
> more flexible than what one can deal with in a formal grammar).

A hand written recursive descent parser will have the best tooling.

If the language it is written in has a good debugger, then the
parser automatically has a good debugger.

This is not true of table driven parsers. They implement an ad-hoc
virtual machine driven by tables, and that virtual machine typically has
next to no debug support.

In a recursive descent parser, you can put a breakpoint on "parse_expr"
and see in the call stack that was called from "parse_statement_body"
which was called from "parse_if_statement" and so on.

That can be an important advantage. Parser generators are still used,
nonetheless. The generated code has good performance, and the
declarative nature has some points in its favor; you just get your shit
debugged in other ways. Some of it can be mitigated by doing the minimal
work in the parser: e.g. just building an abstract syntax tree,
rather than the entire translation scheme.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca