Sujet : Re: question about linker
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 04. Dec 2024, 03:22:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241203181358.493@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : slrn/pre1.0.4-9 (Linux)
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/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca