RE: typing of integer operations in Xpath2

At the general level, I have to say my experience is different. I find that
type checking catches quite a few of my sillier coding errors, and that the
price of doing conversions explicitly is generally worth paying. It is a
fine balance, though, and I agree with you that this particular problem
which arises when (@colspan+1) returns a double rather than an integer is
one that we ought to fix. (The other one I would like to fix is that
concat() should implicitly convert its arguments to strings - even Java does
this).

We have looked at most of the solutions you propose. In my view the right
(i.e. least problematic) answer is (2).

Michael Kay

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of David Carlisle
> Sent: 20 April 2004 10:48
> To: public-qt-comments@w3.org
> Subject: typing of integer operations in Xpath2
> 
> 
> 
> This comment isn't related at a specific document but is rather a
> cross-document comment on the current typing rules.
> 
> I've been trying to write some "new" xslt2 stylesheets (as opposed to
> converting existing xslt1 ones, or simple one-liners 
> answering questions
> on xsl-list).
> 
> I have to say that the type system is a continuous source of 
> irritation.
> 
> In a strongly typed language such as Standard ML in which the type
> system is closely matched to the underlying data and the type 
> inference
> rules, you never (well, almost never) have to explicitly declare the
> types of values, and the type system works as an aid to 
> trapping errors
> early.
> 
> Here though, the type system generates far more errors than 
> it will ever
> catch, almost all the type errors I am getting are due to failures in
> the type inference system and not related to any real underlying error
> in the code. The end result is that I continually have to add explicit
> xsl:integer() all over the place in places that are very hard to
> remember or work out in advance, you are more or less forced 
> to just run
> it and then add the casts until the errors go away, which is a very
> frustrating mode of working.
> 
> If I see
> 
> Required type of second operand of 'to' is xs:integer; 
> supplied value is xs:double
> 
> again I think I'll scream!
> 
> My stylesheet is manipulating unnamespaced-unvalidated elements which
> have lots of integer valued attributes height="3" etc.
> As neither the input nor the output use schema, and the 
> integer type is
> built in to Xpath in the sense that integer literals  and 
> integer valued
> functions are available without explicitly loading the xsd namespace,
> one may have hoped to be able to compute with these values in 
> a natural
> way, but this is not the case.
> 
> You are constantly caught out by the fact that while the 
> attribute value
> may be used directly as an integer, as soon as you do any kind of
> computation with the value (even if all computations 
> logically result in
> integers) you end up with a double. In my stylesheet all input values
> are integers and the only operations I use are:
>  + - idiv min max and sum.
> 
> 
> There are several possible strategies that could be taken to alleviate
> this problem, The Working group would have a better idea than me on
> the possible effects on other parts of the language (you have probably
> considered these already, but it's hard to see how any of 
> them could be
> worse than the status quo)
> 
> 1) all xpath operators and built in functions could use double rather
>   than integer so xs:integer would just be used for 
> validation purposes
>   but all operations would first cast to double. This is 
> effectively the
>   Xpath 1 solution.
> 
> 
> or
> 
> 2) the numeric promotion rules could be extended to allow silent
>    automatic casting between double and integer in the case that the
>    value is actually an integer
> 
> or
> 
> 3) more generally the casting rules could allow silent casting between
>    _any_ two types if the cast would succeed. (I don't think you'll go
>    for this one:-)
> 
> or
> 
> 4) Given an "untyped" value from the source the operations 
> would cast to
>    the required type (as now) but then also untype the result so that
>    I am not caught by this continual automatic casting to double.
> 
> or 
> 
> 5) If the untyped value is in the lexical space of integer the
>    arithmetic operations cast it to integer rather than double
> 
> or 
> 
> 6) ...
> 
> 
> David
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
>

Received on Tuesday, 20 April 2004 08:06:35 UTC