[Monetdb-developers] Fwd: pf/tijah startNodes: node* or string*

Jens Teubner jens.teubner at in.tum.de
Tue May 8 17:13:07 CEST 2007


On Tue, May 08, 2007 at 03:39:03PM +0200, Jan Flokstra wrote:

> Hi Jens,
> 
> Hope you are still in Munich:-) We have a little problem here which we
> do not known how to debug. It is described extensively  in the the
> e-mail at the end of this mail. But the basic problem is we do not
> know how to debug a typing problem. We have the following query:
> 
> tijah:query(fn:collection("c"),"//LINE[about(.,foul)]")
> 
> And the signatures of the function involved are:
> 
> (0) fn:collection (string) as node* 
> (1) tijah:query(string) as node*
> (2) tijah:query(item*, string) as node*
> (3) tijah:query(string, item) as node*
> (4) tijah:query(item*, string, item) as node*

Yes, I am still here.

First of all, the function signatures that you listed here are the ones
that appear in the *comments* in xquery_fo.c.  Unfortunately, the code
says something different!  Very dangerous!  I have corrected this some
minutes ago.

So here's what happens during Core generation and type checking and why
your example makes trouble.  (It boils down to a conflict between the
signatures (2) and (3).)

Out of the possible implementations for a function (tijah:query()),
Pathfinder's function scope checker assigns those to the function
application that have the matching *number of parameters*.  This is in
the spirit of the W3C specs: user-defined functions may be overloaded,
but must differ in the number of arguments (and not just be
distinguishable by their types).  Only built-in functions may be
overloaded in the sense that two functions may have the same number of
arguments, but different argument types.

Then, Core generation in fs.brg looks at the required type for each of
the arguments.  If the function expects an atomic value, the function
argument is *atomized* (i.e., nodes are converted into something atomic,
typically xs:untypedAtomic).  Pathfinder's type checker finally selects
the most specific implementation if there is more than one for the given
number of argument (only really relevant for built-ins).

The problem that you are experiencing is a combination of the two
foregoing paragraphs.  The function scope checker assigns those function
implementations with two arguments to the `apply' node (signatures (2)
and (3)).  Core generation then (randomly) picks on of these two to
determine whether atomization is required.  Type checking finally throws
the error.

This behavior is perfectly okay for all functions we had so far and for
all functions in the W3C specs.  The combination of (a) two function
signatures with the same number of arguments and (b) arguments having a
node type in one signature and an atomic type in the other is what bites
you.

You probably should rethink your two function signatures (2) and (3).
Note that they also introduce some ambiguity.  If I call the function
as `tijah:query (node, node)', should the first or the second argument
be casted to an atomic value?  Note that this implicit atomization
happens everywhere in XQuery (if necessary) and it is perfectly
consistent to do this here as well.

A clean solution would work without such two conflicting signatures.  A
hack could be to treat tijah:query() explicitly in the involved parts in
the Pathfinder code and do something magic to make things work.  I would
not recommend to do so, though, as it primarily would introduce
inconsistency.

Don't hesitate to ask again if my answers weren't clear.

Jens

-- 
Jens Teubner
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259     Fax: +49 89 289-17263

Please avoid sending me MS Word, MS Excel or MS PowerPoint files.
Why? See http://www.fsf.org/philosophy/no-word-attachments.html




More information about the developers-list mailing list