3
Lor-inc
26d

Apparently, writing a parser for a C-like syntax is hard.

Comments
  • 1
    I guess it depends on the method you choose. C-like syntax is quite straightforward, for example something like python is more complicated as you also need to parse whitespaces.
  • 3
    Wait until you try a parser for C++ like syntax.
  • 1
    @Fast-Nop those are the same
  • 1
    Here is a book which might help

    http://craftinginterpreters.com/
  • 1
    @SevenDeadlyBugs It's a streaming parser, the goal is to yield every element as soon as it's technically possible. And actually it's a bit like python because commas and semicolons can be omitted at line breaks.

    @Fast-Nop I'll get there eventually. I'm planning on adding a really smart preprocessor that can scan for recursively enumerable grammars in the tokenized but unparsed code (like regex but more powerful and readable) and hopefully implement most advanced features with that one.
  • 0
    @mr-user Thanks, that looks really useful.
  • 1
    @SevenDeadlyBugs No, they aren't. C++ syntax depends much more on context.
  • 1
    Not really. If you have any actual questions, feel free to hmu, my job is writing interpreters
  • 1
    @yellow-dog I just do it for fun ;)
  • 0
    @SevenDeadlyBugs man you are so wrong it’s not even funny, speaking as someone who has worked on several c and c++ compilers.

    In a word- templates
  • 3
    @Fast-Nop you are also not quite correct; a well written parser does not care at all for the semantics, it just tells you which keywords and operators are attached where in your syntax tree. When you do your first pass into an AST you must now start caring about the context of keywords and or other crap.
  • 0
    Now most verilog parsers on the other hand are written my a bunch of dumb asses and frequently do try to parse with semantic interpretation. That’s why all those compilers suck ass
  • 1
    @Voxera you are a masochist

    Are you single?
  • 0
    @yellow-dog no happily married with two kids :)
  • 0
    link, discussing lisp and o expressions:

    http://breuleux.net/blog/...

    He has an exact handle on the subject. Yes it's about lisp in particular, but the article I think is broad enough to be relevant.
  • 1
    @Wisecrack It's great. And he has many points. Now I'll have to rethink my solution. Fortunately the main part which took me _that_ long was to figure out precedence parsing with a streaming parser that I actually understand (unlike shunting yard).
  • 0
    @Lor-inc not familiar enough to know.

    Heard of shunting yard algorithm, but like a small child that just learned a 'bad word', I couldn't tell you what it means.
  • 1
    @Wisecrack some weird stack-based O(n) streaming AST building algo invented by Dijkstra that I failed to understand. Anyway since I also came up with a stack-based O(n) solution I'm fairly certain that it's the same algo with some unnecessary steps. There are rarely two substantially different stack-based O(n) algos for the same problem.
  • 1
    At least if I make this useful or at least fun I'll finally get rid of my impostor sindrome. God fucking dammit.

    Indeed it isn't as hard as I envisioned, but it will take all my mental capacity to learn all the algorithms and principles involved.

    The best part is that all I actually wanted was a clever config syntax to describe strategy so I don't have to hard-code it. Apparently describing strategy to a computer is an entire science halfway between mathematics and accounting called computer science.
  • 0
    @Lor-inc it sounds really cool and I may not understand it all but I'd be glad if you kept me in the loop with a post or two / progress updates. It's fun to read about technical and theoretical work even if parts of it fly over my head.
  • 0
  • 1
    @Wisecrack I'll also link the repo as soon as I get somewhere with this config/interpreter part. (It's a part, it could have been skipped and I kinda wish it had been, but it's almost done so I won't drop it.)
Add Comment