Re: tolog for TMQL

On Fri, Apr 01, 2011 at 12:20:26PM +0200, Lars Marius Garshol wrote:

> > On the other hand, we do have a deadline for the next draft -
>   June-2011 (a bit more than 2 months from now). And we do plan to
>   implement the language while we standardize it - in order to check
>   that we do not standardize something that cannot be
>   implemented. So I think the process will go a bit faster than you
>   may expect.

> If we really can have a fairly complete and stable draft by June
> then I think this route is the best one. If not, then I think the
> other Lars (and Geir Ove, and Kal, and Graham) are right, and that
> going with tolog is the best option.

One tiny data point from my side: I _did_ analyze tolog very
thoroughly before I drafted TMQL@rho (just as I did analyze other TM
languages, and also what happened in parallel in the RDF space).

   And TMQL became what it is _because of_ tolog.

My concern was and is, that tolog-class languages have severe
limitations in terms of optimization opportunities (need too much
global knowledge and therefore cannot be easily parallelized). With
"semantic clouds" all around us, people talking about billion of
triples, functional language interpreters and multi-core machines
going mainstream, I would find the move towards tolog ....  ....
.... courageous ;-)

If OTOH your envisioned market is "smallish intranet", though, then
that issue goes away. A strategic re-positioning, so to say.

<sidenote>
The other issue I have/had with tolog is, that I never believed that
one is able to _abstractedly_ defined what it does. There seemed to be
too many "pragmatic" decisions based on existing code. But more
importantly tolog is a language derived from datalog. And that is
relatively close to Prolog, i.e. FOL. For reasons of optimization I
wanted to stay away as far as I could.
</sidenote>

\rho