Hi Valentyn, I agree that lambdas in their current form will need to be retired, for the reason you mention: they do not currently have a common representation which can be shared among language variants. Since we are talking about TinkerPop 4, though, I think it is worth talking about whether lambdas, in some *other* form, can be carried forward.
In the context of lambda calculus, a lambda has the structure (variable, term), where any occurrences of the variable in the term are bound to the same type and value. In TinkerPop 3, the body of the lambda is opaque, whereas in TP 4 it would need to have a native representation in gremlin-language. The problem is that gremlin-language right now isn't really expressive enough; it covers the syntax of Gremlin queries perfectly, but it is not a very complete data representation language. GL contains a simple production for "variable", but for terms, it only contains productions for various literals. Since literals cannot contain variables, there is no possibility of representing a lambda body. Variables only occur in the various xxxArgument productions which are provided to traversal methods. The difference between what gremlin-language contains now, and what we would need in order to carry lambdas forward, is a "term" (or "expression", etc.) production in GL. At a minimum, the "term" production must be a disjunction between variables, functions (including lambdas), literals, and applications. I would also add records (which can be seen as a generalization of genericLiteralMap) and variants to that list. Applications are also absent from gremlin-language; while lambdas allow you to introduce functions, applications eliminate them. E.g. the lambda \x.x+x introduces a function which doubles its argument, while the term (\x.x+x)(21) applies the function to an argument of 21, producing 42. In my opinion, two other major missing pieces in gremlin-language, which would fit in well with native lambdas, are a lexical environment (e.g. allowing the user to bind the function \x.x+x to a name like "timesTwo") and a sublanguage for datatypes. Happy to discuss further if the dev group has interest in exploring this direction. Josh On Fri, Jul 5, 2024 at 8:15 AM Valentin Kagamlyk < valentin.kagam...@gmail.com> wrote: > Hi all, > > Lambdas are not supported in Grammar because they themselves are an entire > language, based on Groovy syntax. Current implementation in Gremlin Server > allows Lambdas arbitrary code execution with access to the entire JVM, > which is not optimizable by providers. Also this leads to security problems > that, despite numerous attempts to secure the Groovy sandbox, have not been > successful. > > Since we decided gremlin-language will be the default in Gremlin Server, > the choice to remove Lambda syntax for non-JVM languages and in scripts > sent over HTTP makes sense because this will allow us to have the same > capabilities for different script engines and increase security of Gremlin > Server. Existing scripts that use Lambdas anyway wont work in TinkerPop 4 > because default will be gremlin-language. > > Lambdas can remain for embedded use cases as a form of added/sugar syntax > for steps where they have made sense since their inception. > > Happy to hear any thoughts on the matter. > > Regards, > Valentyn >
