3 ms·

Brilliant, I'm attempting something very similar in Ruby :) Will check out those links. When I have something workable, I'll post it to Github as well and the

Brilliant, I'm attempting something very similar in Ruby :) Will check out those links. When I have something workable, I'll post it to Github as well and then we can see about creating some kind of umbrella structure? A related idea I have is that what is needed is some kind of grammar interchange format, or typing-relation interchange format -- kind of like JSON (or Amazon's ION) but for this sort of work. In some ways that is what S-expressions are, maybe there is no need to reinvent the wheel but my hunch is that a domain specific format is needed. Apologies if this is a bit vague, it's a hunch, and I'm going by intuition.

eric_bullington 11y ago
Check out RAML: https://github.com/raml-org/raml-spec https://github.com/raml-org/raml-spec Maybe it will fit the bill? It can even encode sum types. But I'm not sure if that's what you're looking for. I'll ping you when I put my mini-ml in Python on Github.
- igravious 11y ago
  That's not really what I mean. Take the file `parser.mly` from http://andrej.com/plzoo/html/miniml.html http://andrej.com/plzoo/html/miniml.html . See how it has it's own format for describing grammars. So does Yacc, so does X, Y, and Z. Is there an interchange format for parser generators?
  - kragen 11y ago
    There's BNF, and there's DFDL, and there's just plain lists of productions without the extra decorations in BNF, but basically no. The issue is that each parser generator in current wide use has its particular funky set of limitations that you have to hack around one way or another when you write the grammar for it: it can't handle left recursion, or right recursion, or ambiguity, except in certain special cases (maybe if it doesn't continue for more than one token, or two syntax-tree levels), or it can handle them but has potentially exponential runtime, or it just arbitrarily resolves them in a certain way which may be adequate for your needs or may require you to restructure the grammar, or whatever. And then there are lots of ways that our languages aren't quite context-free, and different parsing systems have different ways to shoehorn that into a basically context-free framework. I think it's maybe a solvable problem, but I haven't seen anyone try to solve it.

eric_bullington 11y ago

Check out RAML: https://github.com/raml-org/raml-spec https://github.com/raml-org/raml-spec Maybe it will fit the bill? It can even encode sum types. But I'm not sure if that's what you're looking for. I'll ping you when I put my mini-ml in Python on Github.

igravious 11y ago
That's not really what I mean. Take the file `parser.mly` from http://andrej.com/plzoo/html/miniml.html http://andrej.com/plzoo/html/miniml.html . See how it has it's own format for describing grammars. So does Yacc, so does X, Y, and Z. Is there an interchange format for parser generators?
- kragen 11y ago
  There's BNF, and there's DFDL, and there's just plain lists of productions without the extra decorations in BNF, but basically no. The issue is that each parser generator in current wide use has its particular funky set of limitations that you have to hack around one way or another when you write the grammar for it: it can't handle left recursion, or right recursion, or ambiguity, except in certain special cases (maybe if it doesn't continue for more than one token, or two syntax-tree levels), or it can handle them but has potentially exponential runtime, or it just arbitrarily resolves them in a certain way which may be adequate for your needs or may require you to restructure the grammar, or whatever. And then there are lots of ways that our languages aren't quite context-free, and different parsing systems have different ways to shoehorn that into a basically context-free framework. I think it's maybe a solvable problem, but I haven't seen anyone try to solve it.