[xsl] Re: What is the best way to cast integer to string in XSLT2?

Subject: [xsl] Re: What is the best way to cast integer to string in XSLT2?
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Tue, 13 May 2003 23:22:16 +0200
>
> There are probably two main justifications for not allowing function
> arguments always to be cast to the required type. The first is error
> checking - as the number of types increases, the risk increases of doing
> a calculation that is different from the one the user actually intended.
> The second is polymorphism. XPath 2.0 doesn't allow functions (as
> distinct from operators) to be polymorphic, but some people would like
> to keep the option open to allow it in future, and weak typing is not
> really compatible with polymorphism.

I do not advocate weak typing. It is possible to avoid unnecessary explicit
casts/conversions with strong typing and still to support polymorphism to
the maximum extent possible.

In Haskell there are type classes. For example:

> class Show a where

> show :: a -> String

> showsPrec :: Int -> a -> ShowS

> showList :: [a] -> ShowS



This defines the class of all types that have a "show" method, which will
present an instance of the datatype to a string.

The type "shows" is a synonym for any function from String to String

> type ShowS = String -> String

-- Minimal complete definition: show or showsPrec

> show x = showsPrec 0 x ""

> showsPrec _ x s = show x ++ s

> showList [] = showString "[]"

> showList (x:xs) = showChar '[' . shows x . showl xs

> where showl [] = showChar ']'

> showl (x:xs) = showChar ',' . shows x . showl xs

As can be seen, the "showList" method can produce the string representation
of any list of things whose type belongs to the Show class. This is the
direct (and really precise) Haskell analog to the XSLT/XPath concat()
function.

As we see, in a well-designed strongly typed language, functions like
concat() may be defined in such a way so that no explicit conversion of the
arguments will be required.



There are many other useful type classes:



Eq  -- a class of datatypes that have the equality operator:



> class Eq a where

> (==), (/=) :: a -> a -> Bool

-- Minimal complete definition: (==) or (/=)

> x == y = not (x/=y)

> x /= y = not (x==y)





Ord -- a class of all datatypes that belong to Eq and also have a total
ordering relation defined:

> class (Eq a) => Ord a where

> compare :: a -> a -> Ordering

> (<), (<=), (>=), (>) :: a -> a -> Bool

> max, min :: a -> a -> a

-- Minimal complete definition: (<=) or compare

-- using compare can be more efficient for complex types

> compare x y | x==y = EQ

> | x<=y = LT

> | otherwise = GT

> x <= y = compare x y /= GT

> x < y = compare x y == LT

> x >= y = compare x y /= LT

> x > y = compare x y == GT

> max x y | x <= y = y

> | otherwise = x

> min x y | x <= y = x

> | otherwise = y



Class Bounded

Class Num



etc.

This is a nice example how unnecessary casts/conversions can be avoided,
while still preserving and supporting polymorphism.

=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL




>
> Most languages end up being a bit pragmatic about this, and XPath is no
> different. In the latest draft, we changed all the functions that accept
> or return URIs to use the xs:string type instead of xs:anyURI, because
> it was simply too much of a pain to keep casting strings to URIs and
> back (though Java makes you do just that). For numerics, we introduced a
> set of promotion rules that allow arithmetic to mix the different
> numeric types.
>
> There would be no technical difficulty in defining concat(), like
> string(), to take item() rather than xs:string as its argument type.
> It's just a question of persuading people that it deserves to be treated
> as a special case.
>
> The place for such comments, of course, is the public-qt-comments list.
>
> Michael Kay
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread