[
https://issues.apache.org/jira/browse/TINKERPOP-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063084#comment-16063084
]
Marko A. Rodriguez commented on TINKERPOP-1551:
-----------------------------------------------
I believe that this is something we should do for TinkerPop4. As it stands,
TinkerPop3 was a successful exploration into the implementation of a Gremlin
virtual machine driven by a {{Bytecode}}. This enabled the various set of GLVs
and distinct languages to come to fruition with relative ease.
For TinkerPop4, we really need to define a stack-based compilation model that
ALL Gremlin virtual machines (not just Apache's Java-based VM) should use for
compilation. This will ensure a consistency of compilation across VMs and will
furthermore, force the bytecode to have a particular format. For example,
{{by}}, {{as}}, {{to}}, {{from}}, etc. should be pop/push based operations on
the compilation stack.
Changing this now in TinkerPop3 (so deep into its development) would create
more issues, than solutions. When TinkerPop4 comes around and all stakeholders
can have a better say as to the instruction set and bytecode specification, we
can start with a fresh slate that includes not only a bytecode specification,
but also a VM specification.
> 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)
