Whoa! — are you saying that we should write an ANTLR parser that compiles Gremlin-XXX into Bytecode directly?
Thus, for every Gremlin language variant, we will have an ANTLR parser. Marko. http://rredux.com <http://rredux.com/> > On Apr 23, 2019, at 5:01 AM, Jorge Bay Gondra <[email protected]> > wrote: > > Hi, > Language recognition engines will give us a set of tokens, usually in some > sort of tree but the result can be thought of nested collections, for > example: > > The following string "g.V().values('name')" could be parsed into something > like [["g"], ["V"], ["values", "name"]]. > > Then, we would have to create some sort of "evaluator", that translates > these string tokens into a traversal, similar to bytecode parsing and > execution. This evaluator can use static evaluation of the tokens (like, do > the tokens evaluate into something meaningful?), can be optimized with > caching techniques (like preparing traversals) and more importantly, will > only execute class methods that are whitelisted, i.e., users can't use it > to execute arbitrary groovy code. > > Best, > Jorge > > > On Tue, Apr 23, 2019 at 12:36 PM Marko Rodriguez <[email protected] > <mailto:[email protected]>> > wrote: > >> Hi Jorge, >> >>> Instead of supporting a ScriptEngine or enable providers to implement >> one, >>> TP4 could be a good opportunity to ditch script engines while continue >>> supporting gremlin-groovy string literals using language recognition >>> engines like ANTLR. >> >> Huh…….. Can you explain how you think of using ANTLR vs >> ScriptEngine.submit(String) >> >>> Language recognition and parsing engines have several benefits over the >>> current approach, most notably that it's safe to parse text using >> language >>> recognition as it results in string tokens, opposed to let users run code >>> in a sandboxed vm. >> >> How would the ANTLR-parsed text ultimately be executed? >> >> Thanks, >> Marko. >> >> http://rredux.com <http://rredux.com/> <http://rredux.com/ >> <http://rredux.com/>>
