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

[Robert Barta]

On Sat, Mar 10, 2007 at 04:11:14PM +0100, Lars Heuer wrote:
> - The TM-ish style adds some syntactic noise to functions / predicates
>   They can be written with less code. I.e.
> 
>   TM-ish style:
> 
>       nr_employees isa tmql:function
>       tmql:return : {
>          fn:length ( $o <- employer)
>       }
> 
>   Traditional style:
> 
>       def nr_employees
>           return fn:length ( $o <- employer)

I definitely buy that argument, that a 'dedicated' function syntax is
more dedicated than a generic TM syntax for functions. That is true by
definition, right? :-)

The downside of a specialized syntax is that - if we want to see these
things as topics, and the TM paradigm allows to do so anyway - it
takes ANOTHER, ADDITIONAL step to explain that. That step would fall away
if we would use a CTM syntax.

What about allowing this in CTM:

  person rho
     shoesize 43

which is saying

  rho isa person
  shoesize: 43

In this vein

   tmql:def nr_employees
       tmql:return fn:length ( $o <- employer)

or dropping the tmql: prefix

   def nr_employees
       return fn:length ( $o <- employer)

would also be a valid topic syntax.

>   The same applies to the documentation for the functions: I assume
>   that the docs are written as occurrences, too. But this practise is
>   more lavish than inventing a special (?) comment syntax which can be
>   used for documentation purposes (like Java Doc, Pyhton docstrings
>   etc.)

Same argument as above.

> - Slower to parse
>   If a parser sees i.e. "def" it knows that it sees a function /
>   predicate / template declaration without involving any TM-related
>   operation. If TMQL uses the TM-ish style, an user can expect that
>   the TMQL-processor accepts something like:
> 
>       my-function iko tmql:function
> 
>       my-return iko tmql:return
> 
>       nr_employees isa my-function
>       my-return: {
>             [...]
>       }
> 
>   To understand that "nr_employees" is TMQL-function causes more work
>   for a TMQL processor than the traditional style would.

Even if this is allowed, the additional 'work' for the processor would
be minimal. At some point it will make a call to the TM infrastructure
asking

   "is nr_employees a tmql:function ?"

You need this functionality anyway 1000000 times when TMQL evaluates.

>   The same applies to surrounding tools, like a simple syntax
>   highlighter. It would be a bit harder to write a simple syntax
>   highlighter without an underlying topic map if everything looks like
>   a topic.

OK, how many people would actually subclass a function? And how many
of those who do will be surprised that a syntax colorizer has
problems?

> - Scope?
>   The examples I've seen so far are all in the unconstrained scope.
>   What happens if the type-instance relationship is scoped? Under
>   which conditions are the functions / predicates are executed?

I am sure I could find an example where this is useful :-)))

\rho