[tmql-wg] TMQL Issue: Functions and Predicates as first-class topics

[Lars Marius Garshol]

* Robert Barta
>
> This is a HIGHLY contentious one. I think I have thought that one
> through, but admit that this is NOT YET IMPLEMENTED in my reference
> implementation. [ I still have this $job. 8-]

I think we've agreed before that this is just syntax. The underlying  
implementation would be exactly the same whether functions/predicates  
were declared one way or the other way. The only area where there  
could possibly be implementation problems is in the syntax.

> Actually, this may not be a TMQL-issue, but a TMCL issue, as TMCL is
> supposed to model an application domain. And functions and predicates
> ***DEFINITELY*** are to model an application domain.

I think you raise a much broader issue here than you actually  
intended to. TMCL at the moment is a pure Constraint Language. To put  
functions and predicates into the current TMCL would look very  
strange, since there would be nothing in TMCL that could actually  
*use* these functions/predicates. They'd just be sitting there for  
TMQL to pick up and use.

In the current, rather simplistic, picture of things, TMCL is a pure  
and simple constraint language, while TMQL does everything that has  
to do with querying. That makes functions and predicates a TMQL issue.

However, you do have a point in that some function and predicate  
declarations could be seen as part of the ontology. (Maybe all  
predicates; probably not all functions.) If we were to aim for a more  
"semantic" stack of technologies, it might be better to do as you  
suggest here, and keep all "data declarations" in one place.

However, this is not the track the process has been headed down so  
far. I'm not arguing that that's good, but I think it's unwise of you  
to argue as you do based on assumptions that I don't know if anyone  
else shares with you, and that you haven't really spelled out. It may  
be better to raise this (what do we want TMCL to be) as a separate  
issue, and argue it through.

I'm afraid some people might, justifiably, think that this discussion  
comes a bit late, but, well, that's life...

> Background
> ----------
>
> If it is accepted that TMQL should contain features to define local
> functions and predicates (which are specialized functions), the
> question is then how this is integrated conceptually and syntactically
> into TMQL.

Ie: discussion of this issue may be premature at this point. :-)

> One option is to use a convential syntax, something like
>
>       function nr_employees (organisation: $o)
>       return
>           fn:length ( $o <- employer )
> 	
> 'function' and 'return' would become TMQL keywords connecting together
> the function name with the function body. The function body - by its
> nature - will always be a TMQL expression.

Yes.

> The parameter profile of the function - here after the function name
> inside a () pair - would specify which variables are to be treated as
> constants, i.e. those where the caller will provide values for at
> invocation time. Additionally, a type (here organisation) can provide
> additional information to the TMQL processor which it may (or may not)
> use.

Yes. However, I think this is a separate issue. How, and whether, we  
specify parameters does not depend on whether we use CTM syntax for  
their declarations.

Personally, I feel very strongly that we should require parameters to  
be declared. The reason is simply readability. It's *much* easier to  
figure out what a function/predicate does if you can see at a glance  
what the parameters are. For one-liners this doesn't matter much.  
When they start getting into 6-7 lines it starts mattering a lot.

(I should know. I've spent the last 2-3 weeks modifying a huge  
existing TM application based on an ontology change.)

> Structured Discussion
> ---------------------
>
>      ? should functions, predicates and templates be first-class  
> topics?

Personally, I don't think so. I think the resulting syntax is uglier  
than a dedicated syntax (and ugliness matters!), and I think it's  
harder to explain to people what is going on. It is, as you say,  
unconventional.

I can't really see that there are any benefits to doing this with CTM  
syntax. Yes, you'd lose a couple of productions. Not a big deal, if  
you ask me.

>           - "it is just a fu**ing syntax"
>             + maybe, but the question is: use yet another new one  
> or re-use an existing one?

It is just syntax, but we have to have one, one way or the other. So  
we need to choose.

>          - it can also be done with conventional syntax,
>            - yes, but then more explanation is necessary how  
> particular
>              syntactic elements have to be mapped onto a TMish view of
>              them

Which is more important? Understanding how functions/predicates are  
declared, or understanding what their TM representation is? I'd argue  
that the former is an absolute necessity, and the latter a nice-to- 
have. Using CTM syntax is optimizing in favour of the nice-to-have.

>      + reduces syntax for TMQL
>        - yes, but it puts some burden onto CTM
>          - which is minimal ({{..

I'm skeptical about changing CTM to allow this to be done in TMQL. If  
we can't do this without changing CTM, then that's another argument  
against this, IMHO.

--Lars M.