4 ms·

You have to start somewhere. Code optimization is utterly useless if you can't parse code.

• sklogic 11y ago
  Quite a few very usable languages are just fine without any dedicated syntax at all. Think of Lisp and Fort for example. And backend is not just about optimisations, they're mostly insig igicant. Backend is about translating gradually one semantics to the other. An example of such is compiling a regular expression into a DFA and then a C array and a switch.
  • jstimpfle 11y ago
    I hope not all future languages will have regular expression, or Forth, syntax...
    • sklogic 11y ago
      I am talking of the languages that are built on top of Lisp/Forth. I.e., you do not really need any syntax if your underlying implementation language is homoiconic.
• nickpsecurity 11y ago
  So write up a grammar, feed it to a parser generator like GOLD, run result through a premade parser engine, and BOOM your done. Then, you can start on the stuff in the middle that really needs more people working on it.
  • jstimpfle 11y ago
    The problem is that writing a good grammar requires understanding of parsers. (Also, real parsers tend to be hand-written, judging from open source language implementations (some have actually migrated from generated parsers to recursive descent in the past). There must be a reason).
    • jcranmer 11y ago
      The reason basically boils down to generated parsers being very brittle. If you need to tweak it slightly (for example, to handle errors on missing semicolons better), it's difficult or maybe even impossible to get the generated parser to do it well.
    • sklogic 11y ago
      The historical reason was error recovery and error messages. It is a solved problem now, you can have it all with generated PEG parsers.
      • jstimpfle 11y ago
        Alarm bells ring in my head whenever someone claims "it's a solved problem" in the context of an engineering (as opposed to mathsy) problem. Unless the context is really narrow (and the problem becomes basically a math problem) that claim is usually wrong. Thanks for pointing to PEGs. I will definitely try them out. But judging from a quick web search, it's obvious that there are perfectly valid reasons not to use a PEG grammar today -- unless someone already designed the grammar for you (and it's PEG!). http://lambda-the-ultimate.org/node/3039#comment-44356 http://lambda-the-ultimate.org/node/3039#comment-44356 http://stackoverflow.com/questions/1857022/limitations-of-peg-grammar-parser-generators http://stackoverflow.com/questions/1857022/limitations-of-pe... Those of us who care about syntax (that is optimized for the user, not the programmer), will have to keep thinking about parsers for the foreseeable future.
        • sklogic 11y ago
          PEG is basically a thin abstraction over recursive descent parsing. Everything you can do in a handwritten parser can be expressed mostly declaratively in PEG. And, no, there is no single reason not to use PEG. Especially when the choice is between a handwritten parser and a PEG. There is a lot of stupid FUD about PEGs, you should ignore it. Your links are pointing to the ignorant, incompetent mumbling of those who never tried implementing a proper PEG. And I never met a language for which writing a PEG parser was not totally trivial. A pro tip: use PEG alongside with a Pratt for the binary expressions.
• _pmf_ 11y ago
  > You have to start somewhere. Code optimization is utterly useless if you can't parse code. It's absolutely not uncommon for architecture experts to plug into the optimization stage of an existing compiler; expecting them to understand the first stages is not useful at all. They need to understand the AST / IR, but not how to arrive at it.