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

[Robert Barta]

Me again :-)

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-]

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.

So it just ends up with TMQL at the moment, but we have to figure
this out anyway.

[ apologies for the length ]

--

TMQL Issue: Functions and Predicates as first-class topics
==========================================================

Impact on Language: very high

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.

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.

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.

Technically it would be sufficient to write 

     function nr_employees ($o)
     return
         fn:length ( $o <- employer )
	
or even 

     function nr_employees
     return
         fn:length ( $o <- employer )
	
if a rule is introduced that all unbound variables (those not
explicitly quantified with FOR, SOME or EVERY) become a
parameter. That rule is implicit already as it would be redundant to
have a parameter list and a list of unbound variables. It would then
be an error if the two lists would be different.

A similar structure and convention can be introduced for predicates 

      predicate is_NGO
      where
         not $o <- part -> whole == // government
	
That checks whether an organisation is part of anything which itself
is an instance of a government (the == is always interpreted
existentially in TMQL!).

If it is also accepted that functions and predicates are actually
ontological information then also a more TMish syntax can be chosen,
especially since the only task is to bind an expression to a name:

      nr_employees isa tmql:function
      tmql:return : {
         fn:length ( $o <- employer)
      }
	
Hereby CTM can be used (AsTMa= here only for demonstration). 
Otherwise, no special syntax is necessary. The {} bracket pair
is used throughout TMQL already to wrap query expressions. 
The only procurement are two predefined TMQL concepts
(tmql:function and tmql:return).

There is, though, an additional requirement for CTM to allow
occurrence values to be wrapped inside {} pairs. By itself this would
imply that a CTM parser has to parse TMQL expressions. To avoid this
burden and to keep CTM parsers independent from TMQL expressions, also
the following can be allowed in CTM:

      nr_employees isa tmql:function
      tmql:return : {{
           .... whatever, even with use of brackets {}
      }}
	
The opening {{ (any number of brackets is possible as prolog) must
only have one matching set }}. This is simple and fast to implement.

For predicates this scheme runs similar: 

       is_NGO isa tmql:predicate
       tmql:where :  not $o <- part -> whole == // government
	
As the syntax of the boolean expression in the WHERE clause is quite
restricted (one cannot generate content with it), there is would be no
need for any terminators. But again, this would imply that an
(embedded) CTM parser would have to understand the syntax of boolean
expressions. To keep that agnostic, the same {} bracketing can be
used; and as above, this is can be kept optional if the end-of-line is
terminating:

      is_NGO isa tmql:predicate
      tmql:where : {{
          not $o <- part -> whole = // government
      }}
	
Structured Discussion
---------------------

     ? should functions, predicates and templates be first-class topics?
     - many people will find this very unconventional, are used to different syntax
       - "un-conventional" is a marketing argument, not a technical argument
          - "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 a TMish view on existing concepts
         + directly reflects a TM-view on functions, no further explanation to a user necessary
         + also predefined functions and predicates can be presented that way
         - 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
     + reduces syntax for TMQL
       - yes, but it puts some burden onto CTM
         - which is minimal ({{..