[sc34wg3] TMQL: Function invocations and names parameters -- Proposal to drop or change them

[Robert Barta]

On Mon, Dec 01, 2008 at 11:20:58AM +0100, Lars Heuer wrote:
> A function invocation with named parameters [37] looks similar to a
> predicate invocation [58].

Yes.

> This leads to the question if a query processor can distinguish a
> function invocation from a predicate invocation in any case (i.e. if
> a function name is equal to an association type)?

Doesn't this issue boil partly down to the question:

   "How do I address something?"

The 'something' being a topic, or a thing, or a function, or an
association type. TMQL tries to approach the addressing issue
TM-ish. So if someone writes

    nr-accounts (owner: "James Bond")

then it NEVER can be a function. It COULD be an assoc predicate,
although the "James Bond" will not make it impossible to satisfy it.

If someone writes

    whatever:nr-accounts (owner: "James Bond")

Then, as you write, this could be a function invocation or an assoc
predicate.

But I figured that processors ALWAYS have to know what their functions
are, those built into TMQL and those imported from the
environment. And Lars Marius ALWAYS insisted that there should not be
ANY visible separation between the "compilation phase" and the
"execution phase".

So I reckoned that it was a safe choice to assume that knowledge.

If we break these phases up, so that we say a processor might not have
any knowledge about what possibly a function is, then we also have to
assume the same for _external_ predicates.

Note here, that these assoc predicates have been intentionally so
designed to allow later on an ontology definition language (not TMCL)
to say

  geneaology:grandfather isa tmol:predicate
  where
     ....

But then we have the same problem that they are indistinguishable.

And unfolding of functions and predicates will be not possible at
compilation time. That is bad news for early optimization.

> I suggest to drop named parameters (even if I love named parameters
> / keyword assignments) or to make named parameters look different
> from predicate invocations.  In an unpublished Topic Maps notation I
> use "=>" to assign parameters to values.

> The TMQL example from 4.12
> 
>     nr-accounts (owner: "James Bond")
> 
> would look like
> 
>     nr-accounts(owner => "James Bond")
> 
> which makes it distinguishable from a predicate invocation.

Possible, but that takes a long look-ahead.

We could also make function invocation using a postfix notation,
instead of the Fortran/C notation most languages are using.

       (owner: "James Bond") !! nr-accounts

We might even consider moving the naming stuff _INTO_ the tuple
expression (so have named columns optionally). That would completely
align (read: simplify) things.

Succus:

  If the assumption is dropped that a processor gets all knowledge
  when it is invoked, then we need to consider 

  (a) to have some syntactic distinction.

  "Consider", because it is still possible to maintain the ambiguity
  until evaluation time. Many languages with late binding (C# 4.0,
  Perl, Python, Ruby) can deal with that. OTOH

  (b) or remove named'ness.

  I would not like to loose named parameters. That would make it
  difficult to have default values and these are good for robustness.

\rho

PS: Good to see how we make the language simpler.