[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
>
>
>
>>In Pizza (or Haskell or ocaml or Scala) one would do like this:
>>
>>Var b = Var();
>>Var authors = Var();
>>FLOWR(
>> For( b, Doc("books.xml").descOrSelf("bib:book"),
>> /* for $b in doc("books.xml") // bib:book */
>> Let( authors, b.descOrSelf("bib:author") ),
>> /* let $authors = b // bib:author */
>> _,
>> _,
>> Return(
>> element("result"),
>> Sequence( b.child("bib:title"), authors )
>> ) /* return <result>{ $b/bib:title, $authors }</result> */
>>)
>>
>>
>>
>
>But that's not exactly XQuery, is it? It's a new query language of your own
>
>
The syntax is different, but I am not sure whether that matters.
Since XQuery has an XML syntax ( http://www.w3.org/TR/xqueryx/ ), one
can argue that there is a canonical tree representation of each XQuery
code fragment. Yes, it is a bit bloated, but these things can easily be
generated by code.
From trees to algebraic datatypes (or just plain classes whose only
constructor takes the "right" types) it is only a little step, easy to
specify and implement. Any XML processing code (be it in Java, XSLT or
XQuery itself) could construct an XML tree representing a query before
shipping it to the DBMS via the driver. I don't see why an abstraction
representation of a program should fail to comply to the language.
>invention. This approach requires a new query language to be designed for
>each host language. You haven't started to address the problems, which range
>
>
I was mainly concerned with Java, but I think any class-based OO
language or one with algebraic data-types
>from incompatible syntax for identifiers between the programming language
>and the database, to incompatible semantics for operators like "=".
>
>
>
The only thing a host language identifier could get bound to is a some
instance of "XQueryThingie" - they do not interact with database idents.
It should be database drivers who are responsible for handling these
things, not application developers!
E.g. in Scala, I could define a function
def $( name:String ):XQueryVariable = Driver.make.XQueryVariable( name );
About operators, you got a point - if I were to use a language that does
not allow me to redefine operators (such that the construction of
XQueryThingies gets hidden), then I might run into problems. Like
$("foo") = $("foo") might compare pointers instead of names.
Again, I did not provide a solution to everything (the string name might
contain rubbish, which gets processed away or rubbish that makes the
Driver fail). But these problems are comparably simpler to solve than
the ones involved in debugging query strings.
>I think this example absolutely demonstrates the difficulties that arise
>with database sublanguages, and the reason they became unpopular.
>
>
>
What has not changed is that programming languages do not really support
integration of domain specific languages well.
But I think compiler technology came a long way. In large scale
projects, one is well aware of advantages of static verification.
Algebraic datatypes make slowly make their way to the mainstream. I
think it is only a question of time when also mainstream language will
come up with things like algebraic types (maybe even Java 1.6 ?).
All this to say, there are better ways today to integrate DSLs like
XQuery available.
cheers,
Burak
|
