RE: SAG-General-01 Static Typing

Some comments:

Treat as and typeswitch are useful even for dynamically typed systems,
although typeswitch can be expressed using if, instance of and treat as
and instance of and treat as can be expressed using typeswitch.

While I plan to implement a fully statically typed system (for
performance reasons), I agree with the sentiment that implementations
should be allowed to infer better types.

The subtyping rules need to be standardized, and probably a miminal
level of inference, but otherwise I do not see a reason to limit an
implementation to do better (examples are typing of parent axis, typing
of fn:root() etc).

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Kay, Michael
> Sent: Tuesday, June 10, 2003 8:50 AM
> To: public-qt-comments@w3.org
> Subject: SAG-General-01 Static Typing
> 
> 
> This comment runs across the suite of XQuery documents.
> 
> Software AG is not planning to implement the Static Typing Feature in
our
> products.
> 
> Although we do extensive static type analysis in products such as
Tamino,
> for the purpose of optimizing queries, we do not think that our
optimizer
> should be constrained by the algorithms in the published formal
semantics.
> Sometimes we infer a more precise type, sometimes (to save time or
space)
> one that is less precise.
> 
> We do not intend to do "pessimistic" reporting of type errors (that
is,
> reporting an error in cases where the expression might or might not
> succeed
> at run-time), except as an extra optional phase for users who want
this
> extra level of checking. In general, we suspect that over-zealous
> reporting
> of type errors will simply encourage users to write functions whose
type
> signatures are very permissive; this effect can already be seen in the
> core
> function library, where functions have been written to accept integer
> rather
> than positiveInteger because callers can't be expected to constantly
> convert
> their integers to be positiveIntegers.
> 
> Since we have concluded that conforming to the static typing feature
> serves
> no useful purpose to our users, we believe that the same is true
> generally,
> and that the feature should be removed from the normative parts of the
> language specification. As a resource for implementors, the
inferencing
> rules in the Formal Semantics are very useful, but we should not
expect
> implementations to conform to these rules as written.
> 
> We also observe that very few people read the formal semantics
> specification, and that it is therefore highly likely that it contains
> surprises and errors. We do not think that we are alone in having
> implementors who are too busy to give this document the attention it
> needs.
> 
> There are a number of constructs in the language that are justified
almost
> entirely for use with products that implement static typing. These
are:
> 
> * treat as
> * typeswitch
> * exactly-one(), zero-or-one(), one-or-more()
> 
> We do not believe that there should be a requirement to implement
these
> features in a product that does not offer static typing, as they
merely
> clutter the product and confuse users. If there is a genuine market
demand
> for interoperability between products with static typing and products
> without, then we might choose to implement these features, but it
should
> not
> be required for conformance.
> 
> Michael Kay
> Software AG
>

Received on Tuesday, 10 June 2003 14:01:09 UTC