tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Novikov <dmitry.novi...@neueda.com>
Subject Re: mm-ADT to TinkerPop3
Date Mon, 17 Jun 2019 15:06:55 GMT
Sorry, at first I've read this with the wrong context. Nevermind my question. It makes sense
now.

On 2019/06/17 14:08:40, Marko Rodriguez <okrammarko@gmail.com> wrote: 
> Hello,
> 
> > Question about 4. Can not fully understand how references are connected with schemas.
Could you please explain it in more detail, or point to explanation if already exists?
> 
> Wow. That is funny you bring this up. I worked all weekend to unify “references”
and “types” in mm-ADT. The short to your question is that a schema is just the unification
of all the defined types. For a better understanding on how references are just types, I've
attached a screenshot of the introduction to the mm-ADT type system.
> 
> Any questions, please ask.
> 
> *** SIDENOTE: I don’t know of any programming language that has realized pointers as
being fundamentally types. In mm-ADT where “anonymous types” (lambda types) are prevalent,
it was a short step to realize that, in fact, any “grouping” is ultimately a new type.
> 
> Take care,
> Marko.
> 
> http://rredux.com
> 
> 
> 
> 
> > 
> > Regards,
> > Dmitry
> > 
> > On 2019/06/14 16:21:55, Marko Rodriguez <okrammarko@gmail.com <mailto:okrammarko@gmail.com>>
wrote: 
> >> Hey,
> >> 
> >>> One thing I wonder at the moment which I don't think has come up in
> >>> relation to mm-ADT discussion yet is DSLs. By every account, people are
> >>> either using DSLs now or as soon as they learn about them, they immediately
> >>> see the value and start to organize their code around them. So, any
> >>> thoughts yet on how DSLs work under mm-ADT (in relation to TP3 and/or
> >>> future) or is the model largely the same as what we do now?
> >> 
> >> mm-ADT is a bytecode specification. While we have a human readable/writable
text representation (currently being called mm-ADT-bc), mm-ADT is primarily for machine consumption.
Thus, when it comes to higher-level languages like Gremlin or a custom DSL, they would compile
to mm-ADT bytecode.  Thus, if Gremlin compiles to mm-ADT, then all the Gremlin DSL infrastructure
would just work as is. However, things can get a more interesting.
> >> 
> >> You can create derived types of arbitrary complexity in mm-ADT.
> >> 
> >> [define,person,[name:@string,age:@int,knows:@person*]]
> >> 
> >> From a DSL perspective, users can make their own objects. Look at the friends
field. It is not container, but just zero or more person objects (sequence/stream). When this
model is embedded in a graph database (and there are different ways to specify the embedding),
those people could be referenced via a “knows"-edge.
> >> 
> >> As you can see, there is nothing “graph” here. No vertices, no edges…
just a domain model.  But with mm-ADT-bc, you can create processes over that domain model
and thus, traverse the “graph”:
> >> 
> >> [db][values,people]      // people is defined, I just don’t show it in this
email
> >>    [has,name,eq,marko]
> >>    [values,knows]
> >>    [value,age]
> >>    [sum]
> >> 
> >> There is nothing pretty about mm-ADT-bc to a human user, but that is where DSLs
would come in. Languages that make it easy to write mm-ADT-bc.
> >> 
> >> If Gremlin were the higher-level language, the following traversal would create
the above bytecode:
> >> 	g.V().has(‘person',‘name’,’marko’).out(‘knows’).values(‘age’).sum()
> >> 
> >> How do you see this being used from your perspective?
> >> 
> >> Marko.
> >> 
> >> http://rredux.com
> >> 
> >> 
> >> 
> >>> 
> >>> 
> >>> On Thu, Jun 13, 2019 at 6:25 PM Marko Rodriguez <okrammarko@gmail.com
<mailto:okrammarko@gmail.com> <mailto:okrammarko@gmail.com <mailto:okrammarko@gmail.com>>>
> >>> wrote:
> >>> 
> >>>> Hello,
> >>>> 
> >>>> Various stakeholders in Apache TinkerPop have been wondering weather
> >>>> mm-ADT can be leveraged in TinkerPop3. While I originally planned for
> >>>> mm-ADT to form the foundation of TinkerPop4, there are a subset of features
> >>>> in mm-ADT that could really help TP3 moving forward. Here is a preliminary
> >>>> outline of the mm-ADT features that could push the TP3 roadmap.
> >>>> 
> >>>>       1. Type system: mm-ADT has a nominal type system for the built-in
> >>>> types and a structural type system for all derived types. Bytecode
> >>>> instructions that CRUD on database data can by statically typed and
> >>>> reasoned on at compile time.
> >>>> 
> >>>>       2. Strategies: mm-ADT has a completely different approach to query
> >>>> optimization than TP3. While there are compile-time strategies for
> >>>> manipulating a query into a semantically equivalent, though computationally
> >>>> more efficient form, the concept of “provider strategies” (indices)
goes
> >>>> out the window in favor of reference graphs. The primary benefit of
the
> >>>> mm-ADT model is that the implementation for providers will be much simpler,
> >>>> less error prone, doesn’t require custom instructions, and is able
to
> >>>> naturally capitalize on other internal provider optimizations such as
> >>>> schemas, denormalizations, views, etc.
> >>>> 
> >>>>       3. Instruction Set: mm-ADT’s instruction set is less adhoc than
> >>>> TP3. Relational operators are polymorphic. Math operators are polymorphic.
> >>>> Container (collection) operators are polymorphic. Unlike TP3, a “vertex”
is
> >>>> just a map like any other map. Thus, has(), value(), where(), select(),
> >>>> etc. operate across all such derivations. Moreover, mm-ADT’s instruction
> >>>> set greatly reduces the number of ways in which an expression can be
> >>>> represented, relying primarily on reference graphs (see #2 above) as
the
> >>>> means of optimization. This should help limit the degrees of freedom
in the
> >>>> Gremlin language and reduce its apparent complexity to newcomers.
> >>>> 
> >>>>       4. References: mm-ADT introduces references (pointers) as
> >>>> first-class citizens. References form one of the primary data types
in
> >>>> mm-ADT with numerous usages including:
> >>>>               * Query planning. (providers exposing secondary data
> >>>> access paths via reference graphs -- see #2 above)
> >>>>               * Modeling complex objects. (will not come into play given
> >>>> TP3’s central focus on the property graph data type).
> >>>>               * Bytecode arguments. (nested bytecode are dynamic
> >>>> references and every instruction’s arguments can take references (even
the
> >>>> opcode itself!)).
> >>>>               * Remote proxies. (TP3 detached vertices are awkward and
> >>>> limiting in comparison to mm-ADT proxy references).
> >>>>               * Schemas. (will probably not come into play, but “person”
> >>>> vertices are possible in mm-ADT. Thus, if TP3 wants to introduce graph
> >>>> schemas, mm-ADT provides the functionality).
> >>>> 
> >>>> I’ll leave it at that for now. Any questions, please ask.
> >>>> 
> >>>> Take care,
> >>>> Marko.
> >>>> 
> >>>> http://rredux.com <http://rredux.com/> <http://rredux.com/
<http://rredux.com/>> <http://rredux.com/ <http://rredux.com/> <http://rredux.com/
<http://rredux.com/>>>
> 
> 

Mime
View raw message