[
https://issues.apache.org/jira/browse/TINKERPOP-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1551.
---------------------------------------
Resolution: Won't Do
Closing according to the last comment...
> Solidify and document Gremlin bytecode specification
> ----------------------------------------------------
>
> Key: TINKERPOP-1551
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1551
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.3
> Reporter: Marko A. Rodriguez
> Labels: breaking
>
> Gremlin Bytecode has a nested list structure of the form:
> {code}
> [operand, argument*]*
> {code}
> ..where an argument can be another bytecode sequence.
> Right now, bytecode has a one-to-one with the {{GraphTraversal}} API. This is
> fine except for in the case of various step-modulators. If we can fold
> step-modulation into the full instruction, then I think Bytecode can be
> specified nicely and easily worked with by language designers.
> Here is the problem with modulation instructions:
> {code}
> ['select','a','b']
> ['by','name']
> ['by',[[bothE],[count]]]
> {code}
> When working with this instruction sequence, you have to "back propagate" the
> {{by}}-modulators to the {{select}}-instruction. As {{by}}-modulation is a
> syntactic device, it should NOT be in the instruction set. The above sequence
> should be represented as:
> {code}
> ['select','a','b',[['values','name']],[[bothE],[count]]]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
