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

Robert Barta rho at bigpond.net.au
Sun Mar 11 00:06:24 EST 2007

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

"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