IRC log of new stuff for Pegex

gistfile1.txt

(11:18:06 AM) SineSwiper: some interesting stuff: http://eli.thegreenplace.net/2010/01/02/top-down-operator-precedence-parsing/
(11:20:42 AM) SineSwiper: especially this: http://eli.thegreenplace.net/2009/03/20/a-recursive-descent-parser-with-an-infix-expression-evaluator/
(11:20:56 AM) SineSwiper: this is exactly the problem I'm having with a_expr and the like
(11:21:45 AM) SineSwiper: and I was close to what the solution was supposed to be: descending levels of recursion
(11:23:17 AM) SineSwiper: ingy: ^^^
(11:34:24 AM) SineSwiper: it's looking like Pegex should be supporting some form of %left/%right syntax

(9:47:03 PM) SineSwiper: ingy: the more I'm converting this, the more I'm thinking there should be a { } syntax in Pegex that introduces an Acmeist "return language"
(9:48:37 PM) SineSwiper: the tree needs to be warped into place, and it's annoying that simple changes like "opt_nowait:   NOWAIT { TRUE }" end up having to be split into two files
(9:48:41 PM) rking: SineSwiper: What do you mean by “"return language"”?
(9:49:12 PM) SineSwiper: well, I guess I'm talking about the evil that is combining the Parser and Receiver
(9:50:06 PM) SineSwiper: of course, we're already controlling what the tree looks like, to some degree, with wrapping, skipping, and () captures
(9:50:21 PM) SineSwiper: why not just keep going?
(9:52:50 PM) SineSwiper: I think the "Receiver language" should have a concept of arrays, hashes, and classes
(9:53:22 PM) SineSwiper: maybe ingy has already invented some sort of language like that somewhere
(9:54:58 PM) rking: Oh.  Sounds like a design decision.
(9:55:09 PM) rking: Might as well make them AST's pretty, though.
(9:56:08 PM) SineSwiper: maybe {} could be in CoffeeScript?
(9:56:17 PM) rking: SineSwiper: Can you code up a failing test?
(9:56:18 PM) SineSwiper: or Uniscript?
(9:56:37 PM) SineSwiper: rking: nothing is really "failing"
(9:57:14 PM) SineSwiper: it's just annoying to try to optimize this Pegex code I have (all 4000 lines of it) without seeing the other side of things (the AST code)
(9:57:36 PM) rking: SineSwiper: No, I just mean can you write out a demo syntax or two (or 50)?
(9:57:54 PM) rking: Ideally in the form of an actual test file.
(9:58:41 PM) SineSwiper: demo syntax would be just like yacc/bison: "rule: thingy? b* c+ { some language }"
(9:58:55 PM) SineSwiper: what actually goes into {}, I'm not sure
(9:59:18 PM) SineSwiper: but in the spirit of keeping Pegex "Acmeist", I'm going for something that would be "universal"
(10:00:02 PM) SineSwiper: lemme see about converting one of these things in that language
(10:06:27 PM) SineSwiper: https://gist.github.com/3785581
(10:06:30 PM) SineSwiper: rking
(10:08:58 PM) rking: SineSwiper: I don't know.
(10:09:39 PM) rking: I'm wondering how far we can get with custom transformation syntax.
(10:09:43 PM) rking: "Put this here, put that there."
(10:13:08 PM) SineSwiper: yeah, it's a bit of a big leap
(10:13:33 PM) SineSwiper: but, I don't know if putting half of your parser code in the AST is ideal
(10:13:43 PM) SineSwiper: it's certainly not Acme-friendly
(10:13:58 PM) SineSwiper: the AST is pure Perl, so it needs translation
(10:15:01 PM) SineSwiper: that's why I'm leaning more towards some sort of proven uniform language that works for all main languages
(10:15:19 PM) SineSwiper: though, it probably shouldn't be overly complex, either
(10:17:46 PM) SineSwiper: Uniscript seems like the right way to go, though I wonder if it needs to be neutered to remove some of the complexity
(10:19:32 PM) rking: SineSwiper: Moar test cases.
(10:20:01 PM) rking: SineSwiper: Ingy will be able to instantly tell you how he wants to solve this, but it'll help him answer you more completely if you load up the test cases.
(10:21:30 PM) SineSwiper: well, I can point to examples within my Eyapp code
(10:22:13 PM) SineSwiper: some of it would get optimized by Pegex grammar, but much of the {} code would be the same