RE: [XQuery] static typing of node comparisons

> > I personally think that having a conservative type checking will
catch
> > more errors and will allow more performing implementations. By
making
> > some of the castings explicit, the user also will better understand
the
> > cost involved in the execution and get the semantics he/she really
wants
> > (and not just the one we came up with for convenience reasons).
> >
> > I also wonder what you think will hurt a user most:
> >
> > A. An early static error when writing a query?
> > B. A late runtime error when executing a query?
> > C. No error but some implicit behaviour that the user may not even
> > expect or understand?
> 
> These are not exactly the choices at present. What we have is:
> 
>    A. An early static error, which in cases may be totally false.
> 
> This is witnessed with pessimisting type checking. The "correction" is
to
> add dynamic-cast functions (one-ore-more(), zero-or-more() and
> exactly-one()) with the total net effect that what is proclaimed to be
> static type checking or even pessimistic type checking in reality
becomes
> dynamic type checking. The benefits of static type checking are gone
in
> this case.

[Michael Rys] Conservative static typing often raises a type error which
is false if the runtime information is taken into account. That is the
nature of it. If you then know that the runtime information is correct,
you add the casts to give static guarantees. This is the trade-off when
using conservative static typing. I do not see this as a problem, but as
a feature. If you can point to some inference rules that are too loose,
we should look at them. But complaining about one of the basis of
conservative static typing (which is only an optional component) is not
very productive, I find.
 
>    B. A runtime error.
> 
> In the cases discussed above it does not come later than if using
static
> type checking + dynamic casts to save it from breaking.

[Michael Rys] Correct. So what is the problem? That the user has to make
the cast explicit and thus has the option?

>    C. No error but some implicit behaviour that the user may not even
>       expect or understand?
> 
> This will happen in cases when in order to save static type checking
the
> type definition is so much relaxed as to make it completely useless --
> e.g. see how min(), max() and avg() are defined in the F&O latest
draft.

[Michael Rys] What is the problem with min(), max() and avg()? Actually
min(), max() and avg() have some special static type rules that are not
given in the F&O document but in a section in the formal semantics.

> This is the worst possible solution.
> 
> >
> > My money is on A hurting the least in the end. Your bet seems to be
on
> > B, and Dimitre's seems to be on C (which I consider the worst).
> 
> I wonder how you arrived at this conclusion. I did strongly react
against
> C. as expressed in my comments in the thread on "[F&O] 15.3 Aggregate
> Functions" in this list -- see for example
>
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0283.html
> 
> What I think is the best decision is to have an early static error
where
> possible and 100% sure, excluding any possibility for false alarms. In
the
> cases when this is not possible the type checking system should
gracefully
> delay its decision till run time. Ideally, this should be implicit and
> should not require that the user specifies explicitly dynamic casts.

[Michael Rys] But the dynamic typing semantics of XQuery gives you
exactly that. I do not dispute that this is what user's most likely
would want ("do what I mean"), but there are systems where the
conservative static typing approach may be preferable. So if you do not
want to use a conservative implementation, don't or lobby the
implementers to provide the dynamic typing semantics as well (while
still doing some static typing).

> So, if we have this definition:
> 
>  fn:max($arg as xdt:anyAtomicType+) as xdt:anyAtomicType
> 
> and we have the expression:
> 
>   max( () )
> 
> then the system will report the error immediately at compile time.

[Michael Rys] But that is different. You do not like that max(()) has a
certain dynamic semantics (that has not only been added to satisfy the
typing gods). There is also this pesky business of mapping to relational
expression systems where max(()) is ().

> If the expression is:
> 
>   max( myElementName )
> 
> where myElementName may or may not evaluate to the empty sequence,
> 
> then the decision if there is an error or not will be done at run time
and
> an error will be raised only if myElementName evaluates to the empty
> sequence.

[Michael Rys] This is a specific implementation strategy to provide
dynamic typing semantics while performing some type checking statically.
There is nothing in our spec that should prohibit this for an
implementation that provides the dynamic typing semantics. But there is
also no reason why we should mandate this.

> This achieves the best from the two worlds -- the first error is
reported
> immediately at compile time, while in the second case there is no
false
> alarm and no need for the user to write:
> 
>   max( one-or-more(myElementName) )

[Michael Rys] Well, if we keep the current max() semantics, there is no
need to do this, is there? :-)
 
Best regards
Michael

> 
> Thank you,
> 
> Dimitre Novatchev
> 
> 
> >
> > Best regards
> > Michael (speaking for himself and not the WG)
> >
> > > -----Original Message-----
> > > From: David Carlisle [mailto:davidc@nag.co.uk]
> > > Sent: Monday, December 01, 2003 1:08 PM
> > > To: Michael Rys
> > > Cc: dnovatchev@yahoo.com; public-qt-comments@w3.org
> > > Subject: RE: [XQuery] static typing of node comparisons
> > >
> > >
> > > > since that would move type checking from the static typing phase
> > into
> > > > the dynamic phase.
> > >
> > > That is true of course, but the solution chosen moves the burden
of
> > type
> > > checking, inserting explicit casts and exactly-one() all over the
> > place,
> > > to the user rather than the system. No one (including the authors
of
> > the
> > > spec, as shown by this thread:-) is ever going to get this right
first
> > > time, so writing xquery is going to be a matter of trial and error
> > > trying to passify the type checker. This completely nullifies any
> > > potential benefits of a static type checker in catching programmer
> > > errors early.  I say Xquery as I would expect (hope) that few
xpath
> > > implementations would use this system. It would be hard to
persuade
> > > anyone that an xpath2 using the static type feature had any
benefits
> > > over xpath1. Some extra useful functions (regexp, mainly) a lot of
> > less
> > > useful functions and a type system that makes using the system
without
> > > without getting errors on the first few attempts at each
expression
> > > virtually impossible.
> > >
> > > David
> > >
> > >
> > >
> >
> >
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/

Received on Tuesday, 2 December 2003 03:22:08 UTC