5 ms·

Much much less than a C++ parser.

• seanmcdirmid 9y ago
  I don't think there is a PL that is harder to parse than C++.
  • tomjakubowski 9y ago
    Perl [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 ago
    I 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 ago
    I 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 ago
      Older 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 ago
        That 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 ago
          It 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 ago
            I 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 ago
    Not yet, but the C++ committee is hard at work at creating the next C++ revision.