4 ms·
I cannot imagine how complex a parser for C must look like.
by sebazzz 9y ago
I cannot imagine how complex a parser for C must look like.
- pkaye 9y agoMuch much less than a C++ parser.
- seanmcdirmid 9y agoI don't think there is a PL that is harder to parse than C++.
- tomjakubowski 9y agoPerl [1] (at least pre-6) and Ruby [2] have good claims too. * [1]: http://www.jeffreykegler.com/Home/perl-and-undecidability http://www.jeffreykegler.com/Home/perl-and-undecidability * [2]: https://programmingisterrible.com/post/42432568185/how-to-parse-ruby https://programmingisterrible.com/post/42432568185/how-to-pa...
- thinkpad20 9y agoI can imagine that parsing Coq is pretty dang difficult since the user is able to essentially define and use their own syntax in the code. Also parsing Agda seems non-trivial, though likely not as hard as C++.
- Someone 9y agoI don’t know whether it is really hard to parse for a computer, but PL/1 may be a good candidate. Its idea that you can’t expect programmers to know every keyword of the language and, hence, the language cannot have reserved words can lead to programs that humans have trouble parsing. A simple example: IF x THEN y = z; ELSE = w; Here, the parser can’t know that ELSE is a variable until it sees the second equal sign. For a more involved example, take a look at http://multicians.org/proc-proc.html http://multicians.org/proc-proc.html (the idea that one cannot expect programmers to know all keywords isn’t a bad one; http://www.cs.vu.nl/grammarware/browsable/os-pli-v2r3/ http://www.cs.vu.nl/grammarware/browsable/os-pli-v2r3/, which claims to be incomplete, has 310 keywords. Drawing the conclusion that one should not have reserved words _is_ a bad idea)
- Retra 9y agoOlder language designers seem to have held natural language as their ultimate syntax, so reserving keywords would be anathema to that goal. It's probably also in direct conflict with efficient parsing. And you still see some people thinking along the same lines when they obsessively over-value "DSL"s and like().writing(all.their.code()).like(*this) In which case, the programmer doesn't have to memorize keywords, but they do have to memorize these obscure, unpredictable, and noncommunicable features of where to properly put their dots and parens. Which is far worse, in my opinion.
- seanmcdirmid 9y agoThat is called a fluent interface (https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface) and is generally frowned on by experienced language and API designers (even of the OO variety). It has nothing to do with language keywords, it is just too far away from operational behavior to be very readable or debuggable.
- kazinator 9y agoIt looks like "fluent interface" resembles "point-free" programming: https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming However, there seems to be a key difference. Under "fluent interface", it looks like the object context is pointlessly being chained and the operations are just side-effecting on it, whereas "point free" programming implements a transformation pipeline by chaining side-effect-free operations. E.g. turtle.rotate(90).pen_down().forward(5); Kind of thing which isn't a pipeline at all, and could be written: turtle.rotate(90); turtle.pen_down(); turtle.forward(5); and arguably should.
- b2gills 9y agoI think using some sort of construct that topicallizes the object is a good middle ground between the two. For example this Perl 6 code: with turtle { # store in topic variable $_ (if it's defined) .rotate(90); # implicit method call on $_ .pen_down(); .forward(5); }
- kazinator 9y agoNot yet, but the C++ committee is hard at work at creating the next C++ revision.
- marmaduke 9y agoIt’s the inverse: simple parser, complex results.
- dfox 9y agoThe grammar is relatively simple. In general having syntactic constructs that are seen as complex by humans (on the grounds of unreadability or counterintuitiveness) says nothing about complexity of the formal language that describes such constructs (and in fact for most practical languages often ugly constructs are the effect of the grammar being simple, not the other way around, for somewhat extreme example of this try comparing say SQL and RPN).
- mpweiher 9y agoC in 4 functions: https://github.com/rswier/c4 https://github.com/rswier/c4
- IncRnd 9y agoParsing c is almost trivial. It is the explanations, such as the article, through disjointed examples instead of the method. A simple way for a human to parse a c type is to start at the identifier, go to the right as long as you can, then go to the left if you must.
- sedachv 9y agoThey are not that hairy. I did a recursive-descent one as a Common Lisp reader macro in less than 1k loc: https://github.com/vsedach/Vacietis/blob/master/compiler/reader.lisp https://github.com/vsedach/Vacietis/blob/master/compiler/rea... C is ok in that you can handle everything (including typedefs) in a single pass with only one character lookahead. This includes the preprocessor. Common Lisp has concatenated streams (http://www.lispworks.com/documentation/HyperSpec/Body/t_concat.htm#concatenated-stream http://www.lispworks.com/documentation/HyperSpec/Body/t_conc...) which made handling the preprocessor really easy, but tcc (https://bellard.org/tcc/ https://bellard.org/tcc/) and I think pcc also do the preprocessing as part of the parser.
- tannhaeuser 9y agoC's type expressions can actually be parsed by a simple operator-precedence parser, and implementing one is very helpful in understanding C expressions. As they say, to understand a language, write a compiler (or at least a parser) for it.
- kazinator 9y agoYears ago, after I wrote an emulator for the MC68000 (68010 actually), I suddenly became very good at coding in MC68K assembly language. Not necessarily in better in organizing big assembly language programs, but just the raw coding of small blocks of code well.