1. 7

  2. 4

    recovering from errors is overrated imo, just give me one good error message. Trying to recover from errors just gives you a bunch of false later errors caused by the original. This post addresses parse errors, but doesn’t really help with all the false semantic errors you get when a syntax error obscures a symbol or type definition.

    1. 2

      Recover doesn’t necessarily mean you continue parsing or something else. The idea is to use as much of the state as possible to construct a useful error message. Often in parsers things are too low level to give a particularly helpful message. Structuring the parser so some higher-level information is preserved can be really helpful to guiding the end-user.

    2. 2

      Regarding the IDE side of things, it seems there would be some value to having the parser depend on the previous parse. E.g. if the user is editing in one “block”, cut that block out and parse it individually in some way, so unbalanced parentheses or string literals don’t affect the whole file.

      (Why is this tagged haskell?)

      1. 1

        I’ve seen parsers implemented as monoids, where you cut the source at semicolons or matched braces or whatever is your chosen chunk delimiter. Seems to work pretty well.

        While your suggestion of depending on previous successful parses sounds like a bunch of work, I can see where it would be very powerful. You could find where the previous source is the same and incrementally parse changes and that kind of thing.

        Also, I think it’s tagged haskell because the blog post uses Haskell syntax? Probably not enough reason for the tag though.