anchor.diff:  
   ==== Traversal Wrappers
   
  -While it is possible to simply interact with Java classes in a `ScriptEngine` implementation, such Gremlin language variants
  -will not leverage the unique features of the host language. It is for this reason that JVM-based language variants such as
  -link:https://github.com/mpollmeier/gremlin-scala[Gremlin-Scala] were developed. Scala provides many syntax niceties not
  -available in Java. To leverage these niceties, Gremlin-Scala "wraps" `GraphTraversal` in order to provide Scala-idiomatic extensions.
  -Another example is Apache TinkerPop's Gremlin-Groovy which does the same via the
  +While it is possible to simply interact with Java classes in a `ScriptEngine` implementation, such Gremlin language
  +variants will not leverage the unique features of the host language. It is for this reason that JVM-based language
  +variants such as link:https://github.com/mpollmeier/gremlin-scala[Gremlin-Scala] were developed. Scala provides many
  +syntax niceties not available in Java. To leverage these niceties, Gremlin-Scala "wraps" `GraphTraversal` in order to
  +provide Scala-idiomatic extensions. Another example is Apache TinkerPop's Gremlin-Groovy which does the same via the
   link:http://tinkerpop.apache.org/docs/x.y.z/reference/#sugar-plugin[Sugar plugin], but uses
  -link:http://groovy-lang.org/metaprogramming.html[meta-programming] instead of object wrapping, where "behind the scenes,"
  -Groovy meta-programming is doing object wrapping.
  -
  -The Jython example below uses Python meta-programming to add functionality to `GraphTraversal`.
  -In particular, the `__getitem__` and `__getattr__` "magic methods" are leveraged.
  +link:http://groovy-lang.org/metaprogramming.html[meta-programming] instead of object wrapping, where "behind the
  +scenes," Groovy meta-programming is doing object wrapping.
  +
  +The Jython example below uses Python meta-programming to add functionality to `GraphTraversal`. In particular, the
  +`__getitem__` and `__getattr__` "magic methods" are leveraged.
   
   [source,python]
   ----
  
positive.code: the reflection-based source code generation technique presented. This method ensures that the language
  variant is always in sync with the corresponding Apache TinkerPop Gremlin-Java release version. Moreover, it reduces
  the chance of missing methods or creating poorly implemented methods. While Gremlin is simple, there are nearly 200
  steps in `GraphTraversal`. As such, mechanical means of host language embedding are strongly advised.
  
negative.code: that are not JVM-based. A theoretical review of the concepts behind the Gremlin traversal machine is provided in
  link:http://arxiv.org/abs/1508.03843[this article].
  
  This section's Gremlin language variant design model does not leverage the JVM directly. Instead, it constructs a
  `Bytecode` representation of a `Traversal` that will ultimately be evaluated by `RemoteConnection` (e.g. GremlinServer).
  It is up to the language variant designer to choose a _language driver_ to use for submitting the generated bytecode and
  coercing its results. The language driver is the means by which, for this example, the CPython
  VM communicates with the JVM.
  