- developers-list - monetdb.org

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz(a)chello.nl wrote: > Hi Jens, > > Indeed you are right, I meant XQueryD. > > As I still do not grasp how the parsing problem manifests itself, I > just applied the changes we desire to the parser/scanner myself (see > below). As far as I can see, this works. The parser reports one more > shift/reduce conflict in state 122 (it now has 3 conflicts instead of > 2, and in total there are 17 instead of 16), which on my fiirst sight > does not seem significant. 42 eq (42) This is quite precisely the problem I tried to describe. Trust me, parsing XQuery is a lot trickier than MIL. (And even that you implemented as simple as possible; think about operator priorities.) > Your characterization of XQuery as a language with little keywords, > makes me appreciate our current syntactical proposal more than a > solution with braces or keywords. If forced to choose between them, I > would go for a keyword. In that case, i would not use "xquery" as this > might put the XQueryD guys into trouble (they want a valid XQuery > after that - we just a function call), but rather propose "function", > i.e. execute at "foo" function bla(1). I'd actually use the same argument the other way round. Using the same syntax as somebody else leaves us room for (maybe) supporting arbitrary XQuery expressions at some point in time. In both, the "curly braces" approach, as well as in the "keyword" approach we could, if needed, easily open our parser to allow any expression. Regards, Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, Indeed you are right, I meant XQueryD. As I still do not grasp how the parsing problem manifests itself, I just applied the changes we desire to the parser/scanner myself (see below). As far as I can see, this works. The parser reports one more shift/reduce conflict in state 122 (it now has 3 conflicts instead of 2, and in total there are 17 instead of 16), which on my fiirst sight does not seem significant. Your characterization of XQuery as a language with little keywords, makes me appreciate our current syntactical proposal more than a solution with braces or keywords. If forced to choose between them, I would go for a keyword. In that case, i would not use "xquery" as this might put the XQueryD guys into trouble (they want a valid XQuery after that - we just a function call), but rather propose "function", i.e. execute at "foo" function bla(1). Peter Index: parser.y =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v retrieving revision 1.47 diff -r1.47 parser.y 353c353 < %token execute_at_lbrace "execute at {" --- > %token execute_at "execute at" 2766,2767c2766,2767 < XRPCCall : "execute at {" Expr "}" "{" FunctionCall "}" < { $$ = wire2 (p_xrpc, @$, $2, $5); } --- > XRPCCall : "execute at" Expr FunctionCall > { $$ = wire2 (p_xrpc, @$, $2, $3); } Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 607,608c607,608 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 776a777,780 > {QName}{_}?"("/[^:] { gotoState (DEFAULT); > pflval.qname = extract_qname (yytext, 0); > yield (QName_LParen); > } > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed AM 11:28:53 CEST > aan: Ying Zhang <Y.Zhang(a)cwi.nl> > cc: p.a.boncz(a)chello.nl, P.Boncz(a)cwi.nl > onderwerp: Re: XRPC syntax > > Hi Peter, hi Jennie, > > On Tue, Oct 24, 2006 at 09:13:00PM +0200, Ying Zhang wrote: > > > I found the formal definition of XQueryD grammar (BTW. it's called > > XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based > > Integration": > > > > ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] > > this syntax actually looks okay to me as well. > > The reason: XQuery is crafted in a way that it uses as few keywords as > possible. To achieve that, the lexical analyzer (a) often recognizes > patterns that are larger than a single word (matching "execute at" > instead of "execute" removes the ambiguity with a child step searching > for an `execute' element) and (b) switches parsing states depending on > the symbols that the lexer sees. > > What we have here is that the lexical analyzer reads an expression. > After reading an expression, it will *always* wait for an operator > (e.g., an arithmetic operator, a sequence constructor, but also `as > type', etc.). In this state it is safe to recognize a lot more keywords > without making them ambiguous with, e.g., path steps. So if we throw in > the `xquery' here, the state machine of the lexical analyzer should run > fine again. `xquery' will be recognized as a keyword whenever an > operator is expected, but not otherwise. > > Peter, Pathfinder's parser is strictly separated as it is supposed to be > in a well-designed parser. There is a lexical analyzer, which is > *independent* of the parser (done with bison in Pathfinder). Being > unaware of any context information, our lexical analyzer thus cannot > know that it currently is somewhere between the two components of an > "execute at" clause. > > If you prefer the above syntax, I could implement that. It should be an > easy fix. Just let me know. > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > No scientist is ever right, they just > can't be proved wrong at the time! > -- Richard Feynman >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens (& Jennie), Thanks for your efforts. As for the syntax, I must say I do not like the idea of the curly braces. Where does that come from? Maybe there is a parsing reason, but if possible, I would avoid them. AFAIK, the DXQ extension by Suciu which also introduces "execute at" did not have that restriction. On another note, during the various phases of query parsing and analisys, we introduced ugly hacks to add a special parameter if the function application was an rpc call. That ugly stuff can now be removed. thanks again, Peter > > van: Ying Zhang <Y.Zhang(a)cwi.nl> > datum: 2006/10/24 Tue PM 06:08:51 MEST > aan: Jens Teubner <jens.teubner(a)in.tum.de> > cc: P.Boncz(a)cwi.nl > onderwerp: Re: XRPC syntax > > On Tue, Oct 24, 2006 at 05:28:48PM +0200, Jens Teubner wrote: > > On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > > > > > What is then the right definition of the grammar rule? > > > > > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > > > > > or > > > > > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > > > > > (BTW, are the braces added correctly?) > > > > It's > > > > XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" > ^^^^ > shouldn't it be ExprSingle? Since we want only _one_ URI string here. > > > > > > (Although it shouldn't really matter in that situation.) > > > > > > I will have to think about how we can implement such a check most > > > > elegantly within Pathfinder. I'm wondering about its usefulness, > > > > though. I accept that we may want to restrict it to non-built-ins only. > > > > But is the import via a module a sensible restriction? i > > > > > > I think it does make sense to filter out XRPC calls to in-query UDFs. > > > If an in-query UDF is called with XRPC, the query just cannot be > > > executed, since we don't want to ship the function implementation in > > > XRPC request. So if such a query is not rejected by the compiler, it > > > will eventually be rejected by the XRPC sender. > > > > In my opinion, it is fine if the sender rejects such stupid queries. We > > will have to check different things there anyway, such as `Is there > > actually a remote XRPC system listening at the given URI?', `Does it > > support the functions that I'm trying to call there?', and so on. > > There's no way we can do such essential tests in the compiler. So why > > do some very hand-waving tests that won't be effective in practice, > > anyway? In my opinion, this is wasted effort (both, in terms of coding > > and in terms of CPU cycles). > > Thus checks don't belong to the compiler, I think. > > > > Maybe we should put even more restriction on the imported module, such > > > as we can require that the imported module should be available in a > > > location which is accessible via the HTTP protocol. This way, we know > > > it for sure that both the XRPC client and the server can access the > > > module definition file (provided there is not further authentication > > > restriction of accessing the file), and both the client and the server > > > access the *same* module definition file, so the argument types should > > > be the same (right?). > > > > You introduced so many conditionals here that I think it only > > strengthens my above point. > > :) > > I will think up other places to do such checks, if necessary. > > > > > > Support for the new syntax, by the way, is now in CVS. > > Thanks! > > > Jennie > > > > > Jens > > > > -- > > Jens Teubner > > Technische Universitaet Muenchen, Department of Informatics > > D-85748 Garching, Germany > > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > > > Be consistent. > > -- `perlstyle' man page >

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 05:28:48PM +0200, Jens Teubner wrote: > On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > > > What is then the right definition of the grammar rule? > > > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > > > or > > > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > > > (BTW, are the braces added correctly?) > > It's > > XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" ^^^^ shouldn't it be ExprSingle? Since we want only _one_ URI string here. > > (Although it shouldn't really matter in that situation.) > > > > I will have to think about how we can implement such a check most > > > elegantly within Pathfinder. I'm wondering about its usefulness, > > > though. I accept that we may want to restrict it to non-built-ins only. > > > But is the import via a module a sensible restriction? i > > > > I think it does make sense to filter out XRPC calls to in-query UDFs. > > If an in-query UDF is called with XRPC, the query just cannot be > > executed, since we don't want to ship the function implementation in > > XRPC request. So if such a query is not rejected by the compiler, it > > will eventually be rejected by the XRPC sender. > > In my opinion, it is fine if the sender rejects such stupid queries. We > will have to check different things there anyway, such as `Is there > actually a remote XRPC system listening at the given URI?', `Does it > support the functions that I'm trying to call there?', and so on. > There's no way we can do such essential tests in the compiler. So why > do some very hand-waving tests that won't be effective in practice, > anyway? In my opinion, this is wasted effort (both, in terms of coding > and in terms of CPU cycles). Thus checks don't belong to the compiler, I think. > > Maybe we should put even more restriction on the imported module, such > > as we can require that the imported module should be available in a > > location which is accessible via the HTTP protocol. This way, we know > > it for sure that both the XRPC client and the server can access the > > module definition file (provided there is not further authentication > > restriction of accessing the file), and both the client and the server > > access the *same* module definition file, so the argument types should > > be the same (right?). > > You introduced so many conditionals here that I think it only > strengthens my above point. :) I will think up other places to do such checks, if necessary. > > Support for the new syntax, by the way, is now in CVS. Thanks! Jennie > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Be consistent. > -- `perlstyle' man page

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > What is then the right definition of the grammar rule? > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > or > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > (BTW, are the braces added correctly?) It's XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" (Although it shouldn't really matter in that situation.) > > I will have to think about how we can implement such a check most > > elegantly within Pathfinder. I'm wondering about its usefulness, > > though. I accept that we may want to restrict it to non-built-ins only. > > But is the import via a module a sensible restriction? i > > I think it does make sense to filter out XRPC calls to in-query UDFs. > If an in-query UDF is called with XRPC, the query just cannot be > executed, since we don't want to ship the function implementation in > XRPC request. So if such a query is not rejected by the compiler, it > will eventually be rejected by the XRPC sender. In my opinion, it is fine if the sender rejects such stupid queries. We will have to check different things there anyway, such as `Is there actually a remote XRPC system listening at the given URI?', `Does it support the functions that I'm trying to call there?', and so on. There's no way we can do such essential tests in the compiler. So why do some very hand-waving tests that won't be effective in practice, anyway? In my opinion, this is wasted effort (both, in terms of coding and in terms of CPU cycles). > Maybe we should put even more restriction on the imported module, such > as we can require that the imported module should be available in a > location which is accessible via the HTTP protocol. This way, we know > it for sure that both the XRPC client and the server can access the > module definition file (provided there is not further authentication > restriction of accessing the file), and both the client and the server > access the *same* module definition file, so the argument types should > be the same (right?). You introduced so many conditionals here that I think it only strengthens my above point. Support for the new syntax, by the way, is now in CVS. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Be consistent. -- `perlstyle' man page

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 04:00:48PM +0200, Jens Teubner wrote: > On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote: > > > Our intention is to allow an XQuery expression here (after "at"), but it > > should be evaluated to a URILiteral. How can I correct this rule to > > express our intention? > > This is a typing thing, and I've already implemented that. Whatever the > expression after "at" evaluates to, we try to cast it into a string. > This is in line with how XQuery is defined elsewhere. > > You cannot express such a restriction in your grammar, though. This is > a pure typing thing. What is then the right definition of the grammar rule? XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" or XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" (BTW, are the braces added correctly?) > > > With or without '{' and '}' doesn't matter for me:) So, if the braces > > make it easier for parsing, we should then just adjust the syntax > > definition. > > Done already. :-) > > > I'd like to mention that we need to check that the called function > > belongs to an imported module, thus it should not be a built-in function > > or a UDF which is in-line with the query. > > I will have to think about how we can implement such a check most > elegantly within Pathfinder. I'm wondering about its usefulness, > though. I accept that we may want to restrict it to non-built-ins only. > But is the import via a module a sensible restriction? i I think it does make sense to filter out XRPC calls to in-query UDFs. If an in-query UDF is called with XRPC, the query just cannot be executed, since we don't want to ship the function implementation in XRPC request. So if such a query is not rejected by the compiler, it will eventually be rejected by the XRPC sender. > I could easily > create some module with some function definition and import it. Still, > the respective function would not be available at the XRPC target > machine. I think we cannot really check whether a target machine will > actually implement a given function > (and if it does so with the same argument types). > So we will have a garbage in, garbage out situation > always. Does it then make sense to do this very special check at all? Maybe we should put even more restriction on the imported module, such as we can require that the imported module should be available in a location which is accessible via the HTTP protocol. This way, we know it for sure that both the XRPC client and the server can access the module definition file (provided there is not further authentication restriction of accessing the file), and both the client and the server access the *same* module definition file, so the argument types should be the same (right?). Is it difficult to implement this restriction? Jennie > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > SQL0437W Performance of this complex query may be sub-optimal. > Reason code: "3". SQLSTATE=01602 > -- IBM DB2 V7.1 Warning Message

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote: > Our intention is to allow an XQuery expression here (after "at"), but it > should be evaluated to a URILiteral. How can I correct this rule to > express our intention? This is a typing thing, and I've already implemented that. Whatever the expression after "at" evaluates to, we try to cast it into a string. This is in line with how XQuery is defined elsewhere. You cannot express such a restriction in your grammar, though. This is a pure typing thing. > With or without '{' and '}' doesn't matter for me:) So, if the braces > make it easier for parsing, we should then just adjust the syntax > definition. Done already. :-) > I'd like to mention that we need to check that the called function > belongs to an imported module, thus it should not be a built-in function > or a UDF which is in-line with the query. I will have to think about how we can implement such a check most elegantly within Pathfinder. I'm wondering about its usefulness, though. I accept that we may want to restrict it to non-built-ins only. But is the import via a module a sensible restriction? I could easily create some module with some function definition and import it. Still, the respective function would not be available at the XRPC target machine. I think we cannot really check whether a target machine will actually implement a given function (and if it does so with the same argument types). So we will have a garbage in, garbage out situation always. Does it then make sense to do this very special check at all? Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 SQL0437W Performance of this complex query may be sub-optimal. Reason code: "3". SQLSTATE=01602 -- IBM DB2 V7.1 Warning Message

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

Hi Jens, First of all, thanks for your help! On Tue, Oct 24, 2006 at 02:55:21PM +0200, Jens Teubner wrote: > Hi Jennie, hi Peter, > > I am currently looking into the XRPC syntax. Primarily I wanted to give > you feedback to what you wrote in your Plan-X submission. > > So you are defining the syntax to be > > XRPCCall ::= "execute" "at" URILiteral FunctionCall > > Lateron, however, you allow more than just a literal URI, but rather an > XQuery expression. So `URILiteral' is definitely wrong here. Our intention is to allow an XQuery expression here (after "at"), but it should be evaluated to a URILiteral. How can I correct this rule to express our intention? > > Once you changed this to, say, ExprSingle, you end up with ambiguity in > your parser. Consider > > execute at "foo" eq ("bar") > > (I couldn't think of a better example ad hoc.) What we have here is an > ambiguity: we don't know whether `eq' is supposed to be a function call, > or if it is the binary operator `eq', followed by another expression in > parenthesis. > > So I will take the freedom to modify your syntax proposal and do it in a > more XQuery-like style: > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" > > This avoids the ambiguity and should make it rather easy to parse. With or without '{' and '}' doesn't matter for me:) So, if the braces make it easier for parsing, we should then just adjust the syntax definition. I'd like to mention that we need to check that the called function belongs to an imported module, thus it should not be a built-in function or a UDF which is in-line with the query. Regards, Jennie > > ...already hacking... > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Time is money. Especially if you make clocks.

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime pathfinder.mx, 1.255, 1.256 pf_support.mx, 1.163, 1.164
by Jan Rittinger 27 Oct '06

27 Oct '06

Hi Peter, your checkin broke the implementation of fn:id() (see the testweb for the tests in benchmarks/XPath and benchmarks/XPathMark). Jan On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions: > Update of /cvsroot/monetdb/pathfinder/runtime > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/runtime > > Modified Files: > pathfinder.mx pf_support.mx > Log Message: > fast NID node retriveal by NID > - moved support for id/idref node retrieval into pathfinder.mx > having this as an API function will allow us to provide this functionality > using indices later (i.e. be able to lock and isolte a hash index). > it also helps a port of this functionality to algebra. > > for the moment, there are no shared hash tables, and ID/IDREF queries > on updatable XML documents will be slowish (sequential scans needed) > the new NID access is a good alternative to look up nodes. > > - implemented in ID node retrieval support for string sthat are numbers, > these are interpreted as NIDs, not ID attributes. > > - implemented a new fn:nid(element()*) as xs:string* builtin function > that returns the NIDs of element nodes. > > - fixed some constant support things (mposjoin) > > > [...] -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

1 0

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 5, Issue 19
by p.a.boncz＠chello.nl 26 Oct '06

26 Oct '06

Yes, a string return type. Hey, it is an identifier ("node identifier"), that sounds more like a string than an integer anyway. And you then you can do id(nid($elt)), i.e. these functions are each others inverse. > > van: monetdb-developers-request(a)lists.sourceforge.net > datum: 2006/10/26 Thu PM 09:22:27 CEST > aan: monetdb-developers(a)lists.sourceforge.net > onderwerp: Monetdb-developers Digest, Vol 5, Issue 19 > > Send Monetdb-developers mailing list submissions to > monetdb-developers(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > or, via email, send a message with subject or body 'help' to > monetdb-developers-request(a)lists.sourceforge.net > > You can reach the person managing the list at > monetdb-developers-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Monetdb-developers digest..." > > > Today's Topics: > > 1. Re: [Monetdb-pf-checkins] pathfinder/compiler/semantics > xquery_fo.c, 1.83, 1.84 (Jan Rittinger) > 2. Upcoming changes in the type system affect existing code! > (Jens Teubner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Oct 2006 17:19:24 +0200 > From: Jan Rittinger <rittinge(a)in.tum.de> > Subject: Re: [Monetdb-developers] [Monetdb-pf-checkins] > pathfinder/compiler/semantics xquery_fo.c, 1.83, 1.84 > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: <4540D1FC.5050604(a)in.tum.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Do you really mean string as return type of fn:nid? > > On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions: > > Update of /cvsroot/monetdb/pathfinder/compiler/semantics > > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/compiler/semantics > > > > Modified Files: > > xquery_fo.c > > Log Message: > > fast NID node retriveal by NID > > - moved support for id/idref node retrieval into pathfinder.mx > > having this as an API function will allow us to provide this functionality > > using indices later (i.e. be able to lock and isolte a hash index). > > it also helps a port of this functionality to algebra. > > > > for the moment, there are no shared hash tables, and ID/IDREF queries > > on updatable XML documents will be slowish (sequential scans needed) > > the new NID access is a good alternative to look up nodes. > > > > - implemented in ID node retrieval support for string sthat are numbers, > > these are interpreted as NIDs, not ID attributes. > > > > - implemented a new fn:nid(element()*) as xs:string* builtin function > > that returns the NIDs of element nodes. > > > > - fixed some constant support things (mposjoin) > > > > > > > > Index: xquery_fo.c > > =================================================================== > > RCS file: /cvsroot/monetdb/pathfinder/compiler/semantics/xquery_fo.c,v > > retrieving revision 1.83 > > retrieving revision 1.84 > > diff -u -d -r1.83 -r1.84 > > --- xquery_fo.c 19 Oct 2006 19:32:27 -0000 1.83 > > +++ xquery_fo.c 26 Oct 2006 12:12:40 -0000 1.84 > > @@ -184,6 +184,11 @@ > > .par_ty = (PFty_t[]) { PFty_opt (PFty_xs_string ()) }, > > .ret_ty = PFty_opt (PFty_doc (PFty_xs_anyNode ())) } }, > > .alg = PFbui_fn_doc } > > + , /* fn:idref (xs:element) as integer */ > > + { .ns = PFns_fn, .loc = "nid", > > + .arity = 1, .sig_count = 1, .sigs = { { > > + .par_ty = (PFty_t[]) { PFty_xs_anyElement () }, > > + .ret_ty = PFty_xs_string () } } } > > , /* fn:id (string*) as element* */ > > { .ns = PFns_fn, .loc = "id", > > .arity = 1, .sig_count = 1, .sigs = { { > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Monetdb-pf-checkins mailing list > > Monetdb-pf-checkins(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > > > > -- > Jan Rittinger > Database Systems > Technische Universit?t M?nchen (Germany) > http://www-db.in.tum.de/~rittinge/ > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Oct 2006 16:43:14 +0200 > From: Jens Teubner <jens.teubner(a)in.tum.de> > Subject: [Monetdb-developers] Upcoming changes in the type system > affect existing code! > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: > <20061026144314.GD11690(a)notekemper14.informatik.tu-muenchen.de> > Content-Type: text/plain; charset=us-ascii > > Pathfinder folks, > > I am currently busy rewriting Pathfinder's type system. In the > short-term view, this rewrite will bring us a much cleaner and > more consistent representation of types, and I'm quite confident > that there will be less bugs in the new code; I have actually > found quite a few in the existing code while doing the rewrite. > > Most importantly, however, on a longer term view, my rewrites > pave the ground to implement also *dynamic* typing in Pathfinder > in an elegant and standards-compliant manner. > > The rewrite will also change the internal representation of types > in Pathfinder. Most of the current built-in primitive types will > become *named* types, in line with the XQuery specs. Most > importantly, this makes Pathfinder highly flexible and easily > extendible with respect to types. > > Unfortunately, there's a bunch of code flying around in the > project that inspects the (current) internal type representation > in a deprecated manner. My changes *will* break such code. This > mainly affects code that looks into the enum field PFty_t.type, a > field that is not (and has never been) supposed to be inspected > by code outside types.c and subtyping.c. milprint_summer.c in > particular is full of such references. ONCE I'M DONE WITH MY > REWRITES, SUCH CODE *WILL* BREAK. > > MY NEXT CHECKIN WILL TAG AFFECTED CODE IN MILPRINT_SUMMER.C WITH > #ifdef'S. WHOEVER FEELS RESPONSIBLE FOR THIS ABUSE OF THE > CURRENT TYPE REPRESENTATION OR WANTS TO RESCUE THE CODE IN > milprint_summer.c FROM DYING CAN USE THESE #ifdef'S TO FIND THE > APPROPRIATE PLACES AND FIX THE RESPECTIVE CODE. I WILL *NOT* FIX > THE AFFECTED CODE MYSELF. > > The "official" way to inspect Pathfinder's types is to use the > functions provided by types.c and subtyping.c. The subtype check > PFty_subtype() is the function that allows most of the checks > against types that one ever needs. Additional helpers can be > PFty_prime() (which normalizes a structured type to have the form > `t1 | t2 | t3 | ...') or PFty_quantifier() (determining the > quantifier, `0', `1', `?', `+', or `*', of a given type). > > The test whether a type t is the type `xs:string' may, e.g., > implemented by testing > > PFty_subtype (t, PFty_xs_string ()). > > (Some care has to be taken, though, that this is a *subtype* > relationship. Often, this is what you actually need. If you > want to test for type *equivalence*, use PFty_equality(), which > applies the subtype test in both directions.) > > Quantifiers are usually tested with a subtype test against a > regular expression over the `item' type. > > PFty_subtype (t, PFty_item ()), > > e.g., tests whether the quantifier of t is exactly one. > > You may want to look into other pieces of our code, e.g., > core2alg.brg, to see how PFty_subtype() and others can be used to > test types. Just watch out for invocations of PFty_subtype(). > > If you need any further assistance regarding types, just contact > me. > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Unix is user friendly - it's just picky about it's friends. > > > > ------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ------------------------------ > > _______________________________________________ > Monetdb-developers mailing list > Monetdb-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > End of Monetdb-developers Digest, Vol 5, Issue 19 > ************************************************* >

1 0