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. 

[Dimitre Novatchev] One can never "know that the runtime information is 
correct". This is why the dynamic casts have to be added in all (but the 
most trivial cases) and what we've got is really a dynamic type-checking,
pretending to be "Conservative static typing". In fact it is really a 
bad form of dynamic type checking, bad because the users must explicitly 
turn it on rather than simply do nothing. In fact, the users must be 
very educated, because turning the dynamic type checking in this case
requires different dynamic casts in different cases. Also, when an user 
forgets a dynamic cast he gets punished by a (false!) error message  
and may even feel guilty.

[Michael Rys] This is the trade-off when using conservative static typing.

[Dimitre Novatchev] So what's the use of this? It's really a pain. 
Why should a user "give static guarantees" to the system? Is the system 
really serving the user? No, in this case the user is to serve the system.
Don't ask me if this is good. It's bad, bad, bad. I'll even pay if 
it's possible to remove this "feature" from a system as many people 
pay these days to remove pop-up windows.

[Michael Rys] 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.

[Dimitre Novatchev] I as a user do not need such a feature. Moreover, 
I express my understanding that it is definitely bad and should not 
be an option.
I believe that providing this most definite feedback when it is still
not too late is the most productive help a user can give to 
a developer.
 
>    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?

[Dimitre Novatchev] The problem is that the user has the "option".
Because,
if he forgets to use "the option", he'll be punished -- see above.

>    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.


[Dimitre Novatchev] The problem is that I have to write my own checks on 
every call to one of these functions just to see if they didn't return 
the empty sequence.

If that was the case, then I have again "the option" (this is no option --
this is the only sensible thing one must do) to call the error() function.

The problem is that XPath 2.0 and F&O were supposed to give us
type-checking and what we have in this case is really the lack of it.

Why shall one have to write their own wrapper with the correct signature
around almost every F&O function just to ensure the necessary and really
useful type-checking that would really simplify the programmer's work?
Isn't it ironic that the purpose of type-checking is to relieve the
programmer from doing such checks manually and provide this form of
type-safeness?

> 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. 

[Dimitre Novatchev] David Carlisle answered this in the best possible way
and I am glad to repeat his statement:

<quote>

  And note again, if you operate without the conservative static typing,
  you do not have the issue.

This argument is simply not true, the fact that the dynamic behaviour
has to be compatible with the currently specified static typing has
affected the entire design of the language.

Also many of us do not work in closed environments. We distribute code
that is intended to run on any (all) systems, by unknown users.
Anyone who tries this in the future is going to be swamped with "bug"
reports from end users who are trying to run code on a system using this
static typing.

</quote>


Best regards,

Dimitre Novatchev.

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Received on Tuesday, 2 December 2003 09:31:06 UTC