tegola
tegola copied to clipboard
go-spatial
Move away from the hand coded parsers to PEG
Right now we have a couple of hand-coded recursive descent parsers. We should really just write up a formal peg grammar and run pigeon on it.
https://github.com/mna/pigeon
This will not be a vendor program as it will only be used to generate the source that will be checked in.
@gdey can you reference the parsers you're thinking we should use pigeon on in case someone else wants to pick up this issue?
@gdey, I second @ARolek's interest in mentioning the specific parsers. The only ones that come to mind are the wkb/wkt processing.
Right now that's it. It's just the wkb/wkt processing. Once for the testfile for wkb and the other for wkt.
Eventually, I think it would be good for the postgis driver to have an SQL parser; that way we can be smarter about the sql that is given to us. More of something I want to do then is really needed. I don't think the hand coded one's I've written are bad; but a peg file is easier to read. I was going to write up a YACC file, but I'm not a fan of yacc; and go built in yacc tool seems not be maintained or well documented. I did look at https://github.com/goccmack/gocc ; but it too isn't maintained, and is harder to do proper unicode classes. I've used pigeon on my side projects, so I know it's easier to the unicode classes. I went looking for compiler compilers for one of my side projects after I got tried of hand coding them using bufio.Scanner interface. Though the Scanner interface works really well for simple processing needs, and with the little hack you can even have proper token support. Though mainting line, char, and pos support is more of a hack. This you just get a proper compiler compiler. Anyway, I getting off topic.
I gave this a shot at https://github.com/go-spatial/geom/pull/28 Interested in any feedback there.
I haven't finished the tests and a lot of the code can be condensed but It would be good to know if this is the direction the team was thinking.
