Re: tolog for TMQL

On Tue, Apr 05, 2011 at 01:08:48PM +0200, Lars Marius Garshol wrote:
> 
> * Robert Barta
> > 
> > - tolog allows to quantify over literals, i.e allows to have
> >  variables range unboundedly (TMQL@rho never does allow that)
> 
> No, this is not allowed.
>
> str:length($A, 5)
> 
> is not legal.

Parsing or processing-time "not legal"?

I can now hear you saying "aaaaaaaaaaah!". :-)

> There's just as much state in a path language. The difference is
> whether the values have names or not.

It is subtle, and then - at that level - not:

With PEs there is more burden on the query author to craft the queries
along the concepts of the topic map. Variables are/can be explicitly
bound to values, navigation is rather explicit, etc.

With a logic/datalog language NOTHING is actually using the TM
structure. If the underlying data were, say, a relational database,
then the query would work all the same. So PEs are more low-level. It
is only a truism that there are then more direct pathways for
optimisation.

Now tolog is not a datalog language, per se, as it hardcodes certain
predicate (name, ...) into the core. But it still carries over the
syntactical structure how variables are scoped.

[ BTW: I cannot remember having seen subquery functionality in tolog. ]

> > I transformed a
> > 
> > for $p in // person
> > where
> >    is-author (author: $p, opus: $_)
> > 
> > into a chain of PEs which did not contain a single variable. The
> > semantics appendix in TMQL@rho has a complete transformation defined.

> What does it matter if there are variables or not? Surely what
> matters is how/whether you can compose/decompose query expressions,
> and not whether there are variables.

The issue is - as always - the _locality_ of the information. Here I
still contend that PEs - by definition - have a narrower/constrained
way to pass on information.

\rho